Re: Newbie: How do I handle this directory structure?

From: patrick_at_[hidden]
Date: 2001-09-12 04:26:59

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
[...]
> > 2. No intermediate libraries, because all C++ static objects
> >    need to be initialized at startup
> 
> I'm not sure what this means. Could you elaborate? Intermediate
> statically-linked libraries, at least, don't normally interfere
> with static initialization.

At least under VisualC++, static C++ objects don't get initialized at program startup. Static objects initialization is postponed until the first time a function within that module (.cpp) is called. This can be  worked around, but we preferably don't use any libs for this reason.

> > 3. No need to write out dependencies at the lowest level
> >    (MinorProject to individual .cpp files)
> 
> I really have no clue what this one means.

I mean I don't want to write out that the pseudotarget MinorProject11 is dependent on all .cpp in that directory. I would like a rule called minorproject which does something like:

rule minorproject # First argument is the pseudotarget
{
  source_files = all-cpp-files-in-directory($(1))
  DEPENDS $(1) : source_files 
}

So I can write:

minorproject MinorProject11

instead of:

DEPENDS MinorProject11 : MinorProject11File1.cpp MinorProject11File2.cpp MinorProject11File3.cpp

The problem is that new files are added quite often and I don't want to add them manually, instead I want jam to do it for me :-)

Is it possible to write the rule all-cpp-files-in-directory at all? I can not find any clues in sample jamfiles or in the documentation on how to write it. 

> > MajorProject2
> > MinorProject21
> > MinorProject21File1.cpp
> > MinorProject21File2.cpp
> > MinorProject21File3.cpp
> > ...
> > MinorSubProjec212
> > MinorProject22File1.cpp
> > MinorProject22File2.cpp
> > MinorProject22File3.cpp
> > ...
> > MinorProject23
> > MinorProject23File1.cpp
> > MinorProject23File2.cpp
> > MinorProject23File3.cpp
> > ...
> > ...
> > ...
> > Executable1 # depends on MajorProject2, MajorProject7 and
> Executable1MainFile.cpp
> > Executable1MainFile.cpp
> > Executable2 # depends on MajorProject6, MajorProject8 and
> Executable2MainFile.cpp
> > Executable1MainFile.cpp
> > ...
> 
> Are you saying that minor projects have exactly 3 source files?

No, the number of files is variable and can change. Therefore I want to generate the dependencies of the MinorProject on it's source files dynamically.

> > I was thinking of a kind of jamfile at the MajorProject level
> > that is generic. It makes that pseudotarget MajorProjectN
> > automatically dependent on all the .cpp files in it's
> > MinorProjects (*/*.cpp).
> 
> That would work fine if you use static libraries for the minor
> projects. If you want to be able to create pseudotargets that
> correspond to groups of object files, you'll have to define your
> own target type (examples of that can be found in the Jamfiles in
> boost's status and libs/python/build directories). There may also
> be some build system hacking needed; I'm not sure.

I suspect all-cpp-files-in-directory can not be written, except by hardwiring it into the source.

> I may be able to address this for you, since I am currently
> re-starting my work on the build system... but there's a lot to
> do first, so if you can make progress on your own, that would be
> much better for both of us ;-).

Probably, but I know so little about the system that I don't even know if it is possible to write a builtin rule that can be used in a jamfile. Otherwise it could probably be added as a new variable modifier?

> > DEPENDS Executable1 : Executable1MainFile.cpp MajorProject2 MajorProject7
> ;
> 
> I don't think you want the DEPENDS rule here. You'll need more
> than that to generate proper build instructions. Probably the
> "exe" rule is the right one for you.

You're completely right of course.

> I think your goals are reachable. I even see that they are not so
> esoteric: builders of dynamic libraries who want to ship a single
> unified DLL instead of many separate ones might need this,
> because apparently it doesn't work to link static libraries with
> exported symbols into a dynamic lib on all platforms.
> 
> Probably, you'd have to learn a bit more about how the build
> system works to accomplish it, though.

That's for sure, but I see possiblities if I can somehow generate the dependencies os MajorProjects on MinorProjects on it's source files dynamically using some (hardwired?) rule.

> 
> HTH,
> Dave

Thank you for your response!

Patrick

--
Patrick Frants
Senior Software Engineer
Quintiq BV
Het Wielsem 10
5201 AG 's-Hertogenbosch
Phone: [phone]
Fax: [phone]