[ros-dev] rbuild and HALs module optimization

[art yerkes]

On Fri, 21 Sep 2007 19:48:24 +0200
David Hinz <post.center at gmail.com> wrote:

> 
> Aleksey Bragin schrieb:
> > 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...

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