22 Sep
2007
22 Sep
'07
2:55 a.m.
On Fri, 21 Sep 2007 19:48:24 +0200
David Hinz <post.center(a)gmail.com> wrote:
Aleksey Bragin schrieb:
Sorry, I've been somewhat taken up while this email thread was going.
Here's what I want to see in rbuild:
1) Remove platform specific settings where possible from rbuild and
place them in named variables, and park the variables in the .rbuild
files per architecture.
This just means moving things like
string linkerParameters = ssprintf ( "-Wl,--subsystem,console -W
l,--entry,%s -Wl,--image-base,%s -Wl,--file-alignment,0x1000 -Wl,--section-align
ment,0x1000 -shared",
module.GetEntryPoint(true).
c_str (),
module.baseaddress.c_str ()
);
Into variables like:
<property name="default_WIN32OCX_LINK">-Wl,--subsystem,console
...</property>
And make them overridable so that:
<!-- need this on elf platforms -->
<property name="HHCTRL_LINK">-Wl,-z,defs ...
$(HHCTRL_ADDLINK)</property>
Supporting entities for common things like variables that will be expanded
with target names would be good too.
Like this:
<!-- force the linker to include the entry point -->
<property
name="HHCTRL_ADDLINK">-Wl,-U,&entryPoint;</property>
Where &entryPoint; is expanded to the entry point set for the current target.
2) Reduce the number of targets by turning them into a smaller number of
configurable meta-targets and creating the final targets using xml
input.
An example target definition would be something like this:
<defineTarget target="ntoskrnl" base="targetModuleRules"
for="mingw">
<add
stage="linker">-Wl,-T,$(&module;_MODULEBASE)/ntoskrnl_$(ARCH).lnk</add>
<add stage="linker">-Wl,--subsystem,native
-Wl,--entry,&entryPoint;</add>
<add stage="linker">-Wl,-nostartfiles</add>
<!-- ... more ... -->
<outline>
<!-- would expand to the same thing as GenerateCommands compilation
parts -->
<perform>compile</perform>
<perform>link</perform>
<perform>postlink</perform>
</defineTarget>
Then you can use <module type="ntoskrnl">...</module> in your
rbuild input
and you can even make these conditional on architecture in the build rules.
--
"Ask Bill why the string in function 9 is terminated by a dollar sign. Ask him,
because he can't answer. Only I know that".
- Gary Kildall
David, what does a kernel-dev have to do with
rbuild?
I just guessed that as HAL is very near to the kernel, it would be
maintained by a kernel-dev, who could answer in detail, why we have
certain different hals (I'm referring to differenciating between
x86-generic, x86-xbox etc., not between x86 and PPC).
Also, recent massive commits to the rbuild
itself, and to
various .rbuild files hardly prove your "rbuild is an umaintained
piece of ... stuff" theory. It's, by the least measure, offensive to
Herve's (and there were a few different patches submitted by various
authors submitted) work he's been doing with rbuild.
I surely noticed him
working there, that's why I said he might have an
oppinion on that matter.
Or what is a "maintained rbuild", by your definition? How more should
it be maintained? Note: not improved (we have a number of
improvements pending to be implemented in it), but *maintained*.
Well for me, a
maintainer is the one who cares about that piece of code,
integrates patches, implements features, cleans up and so on and can be
contacted regarding that piece of code, even if he isn't currently
working on it. As I stated above I noticed Herve working in there, but
it didn't look like he was the new maintainer, more like he was doing
some stuff that just had to be done to keep rbuild working (I don't want
to disregard that work, I know that it was quite a lot he did in there
recently).
But good to know rbuild has a maintainer.
Another thing is completely wrong and counter-productive: irc is a
wrong place for such question, since not all devs are there all the
time.
I didn't want to keep him from posting here, but I know devs tend to
have way to less time, so you sometimes have to make them aware of
something.
Sorry for mixing up just about everything in my first mail...