[openbeos] Re: building not so custom targets
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 25 Dec 2003 16:48:23 +0100
On 2003-12-24 at 20:00:31 [+0100], Andrew Bachmann wrote:
> Jérôme Duval <korli@xxxxxxxx> wrote:
> >
> > 1/ i need to build two targets with the same files.
> > Should i do something like this ? Am i sure it'll CC two times the file.c
> > and
> > not reuse the first one ? Is it the way to do this ?
>
> Like this: (untested)
>
> #
> Object <prog1>file.o : file.c ;
> CCFLAGS on <prog1>file.o += -DPROG1 -Wall -Wno-multichar ;
> C++FLAGS on <prog1>file.o += -DPROG1 -Wall -Wno-multichar ;
>
> R5KernelAddon prog1 : bin ;
> MainFromObjects prog1 : <prog1>file.o ;
This will not work, for MainFromObjects sets the grist of the object files
passed to it to the subdirectory's grist.
> Object <prog2>file.o : file.c ;
> CCFLAGS on <prog2>file.o += -DPROG2 -Wall -Wno-multichar ;
> C++FLAGS on <prog2>file.o += -DPROG2 -Wall -Wno-multichar ;
>
> R5KernelAddon prog2 : bin ;
> MainFromObjects prog2 : <prog1>file.o ;
> #
>
> You may want to use ObjectCcFlags instead of the "on" construct. I think
> that they are equivalent.
Almost, with the difference, that the ObjectCcFlags applies the grist of the
subdirectory, so that it won't work when you deal with the grist yourself as
done in this case.
> You might have to MakeLocate the two file.o
> in different places, or you might not. I'm not sure.
By default both object files would be placed in the same directory, so, as
Axel wrote, only one will be correct (not always the same, BTW, since, when
no changes are made to the source file, each invocation of jam will update
the respectively other object file).
Anyway, the Object rule already does a MakeLocate to the LOCATE_TARGET. This
variable is usually set by the SubDir rule to the subdirectory. After
migrating the build system to jam 2.5 the the variable will be set to the
correct directory (objects/...) by SubDir itself, but for the time being the
SetupObjectsDir should be invoked directly after the SubDir rule.
This is usually not necessary, because our custom rules (App, Command,
SharedLibrary,...) do this already (even if it's a bit ugly this way).
Andrew's proposal can be fixed adjusted to the following:
SetupObjectsDir ;
Object [ FGristFiles file1.o ] : [ FGristFiles file.c ] ;
ObjectCcFlags file1.o : -DPROG1 -Wall -Wno-multichar ;
ObjectC++Flags file1.o : -DPROG1 -Wall -Wno-multichar ;
R5KernelAddon prog1 : bin : file1.o ;
Object [ FGristFiles file2.o ] : [ FGristFiles file.c ] ;
ObjectCcFlags file2.o : -DPROG2 -Wall -Wno-multichar ;
ObjectC++Flags file2.o : -DPROG2 -Wall -Wno-multichar ;
R5KernelAddon prog2 : bin : file2.o ;
Also untested. :-)
CU, Ingo
Other related posts:
