[openbeos] Re: Build changes

On 2005-08-21 at 19:26:41 [+0200], Axel Dörfler wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On 2005-08-21 at 14:30:32 [+0200], Axel Dörfler wrote:
> > > Right, I did not think of this very common case either. Having a
> > > full
> > > debug build is often not quite what you want, you usually only
> > > compile
> > > those parts with DEBUG you're currently working on; otherwise
> > > system
> > > output could get way too noisy.
> > > Any idea about that?
> > Actually yes. I plan to introduce a central place for customizing the
> > build
> > (in the OT locale kit build system it's build/UserBuildConfig). Among
> > others you will be able to set the DEBUG variable at least per
> > directory
> > (could be hard doing that per object file), which will cause the
> > concerned
> > targets to be placed in a different directory. Pretty much what
> > Andrew did,
> > with the difference that the build system "knows" where a target has
> > been
> > placed. makehdimage will go away or at least be generated by the
> > build
> > system (only some fragments like the generation of the MIME DB might
> > remain
> > as scripts).
> 
> That sounds good, although it doesn't help in all cases, namely:
> 1)  we have some scripts that directly execute binaries from the distro
> /... tree, ie. "rc", "haiku_app_server", ...

I would think of a rule that, given a list of targets, generates a shell 
script defining variables with the targets' paths. Such a script can be 
"sourced" from any script that wants to access the targets.

> 2) there are usually symlinks from ~/config/lib/ to some libs like
> libopenbeos.so or libhaikuappserver.so to be able to run apps under R5
> in the test environemnt
> 
> At least the second item could be solved by having those apps in a
> dedicated output directory (that would be "test" right now), and also
> have the libs put in there so that they are found.

Definitely a wise solution anyway, avoiding clashes of the test libraries 
with those in your running system.

> I also have a couple of scripts that update only a certain component on
> either a target partition or image - very handy and time saving.

With your local UserBuildConfig you can generate sourcable shell scripts to 
fit your needs.

> > > The only one that comes to my mind is to introduce another variable
> > > that lets you override the target directory for those components,
> > > ie.
> > > somelike like either:
> > > $ DEBUG=1 TARGET_TYPE=release jam
> > > or:
> > > $ DEBUG=1 RELEASE_TARGET=1 jam
> > If I understand you correctly, that would force the targets to be
> > misplaced
> > in the release directory although they were built with debugging?
> 
> Yes, that would allow makehdimage and other scripts to behave correctly
> for now (until the build system is changed).

Alternatively the "release"/"debug_*" part could be removed from the output 
directory names for the time being.

CU, Ingo

Other related posts: