3 messages in com.perforce.jammingRE(2): conditional includes
FromSent OnAttachments
C.Co...@slh0633.wins.icl.co.uk C.Coles@slh0633.wins.icl.co.uk12 Feb 1997 02:25 
Hunt...@redhat.com12 Feb 1997 09:48 
Tim ...@ftlsol.com12 Feb 1997 11:23 
Subject:RE(2): conditional includes
From:Tim ...@ftlsol.com (Tim @ftlsol.com)
Date:02/12/1997 11:23:41 AM
List:com.perforce.jamming

C. Coles writes:

Has anyone successfully incorporated gcc's .d files into Jam? A nice byproduct of this would be a big speed-up---no more parsing of files on the fly.

Also, while we might like to use gcc everywhere, it's not always an option.

I agree, jam looks *really* portable, whereas porting gcc first seems a little more of a task. :-)

I've heard it said, "the only portable code is ported code." By this measure, gcc is highly portable. But you're right, I wouldn't dream about porting gcc to a new architecture myself.

But even if gcc is available (usually the case), there may be other reasons (sometimes political, sometimes technical) why its not an option. For instance, I'm currently porting an MFC application to Solaris using Wind/U. Since the Wind/U MFC wasn't compiled with g++, I can't use it. :-(

You can workaround this problem by supplying an explicit depend target. Then it becomes the responsibility of the programmer to know when to run make (or jam) depend. But we all forget sometimes and at

I've often thought that this problem could be solved by having 2 or 3 Makefiles in each dir, one to generate the dependencies into another one that does the build (or includes the dependency info, whatever). Then a top level Makefile that invokes the other two accordingly. Obviously a little untidy having many makefiles, but achievable and probably with one Makefile by recursive invocation (but a little obscure).

In the current implementation of Jam I don't think it *is* possible except recursively because the -f option selects a Jambase file not a Jamfile. Am I wrong in this or have others hit the same problem of wanting to have two different Jamfiles in the same directory? I would have expected command line options to override both the default Jambase and the default Jamfile, and the -f option do the Jamfile to retain closer parallels with make.

Yes, this approach is difficult, if not impossible with Jam. I tried something similar using Jam's "include" directive but it doesn't work because of Jam's distinct binding and updating phases. Consider:

rule Depend { DEPENDS depend : $(<) ; # for jam depend DEPENDS $(<) : $(>) ; MakeDepend $(<) : $(>) ; # update dependencies include $(<) ; # and include }

actions MakeDepend { # run makedepend or gcc or whatever to generator $(<) from $(>) }

Main prog : $(SRCS);

Depend deps : $(SRCS) ;

[ This is completely off the top of my head so excuse any glaring errors. ]

This doesn't do what you want because Jam decides which object files to update (binding phase) before updating "deps" (updating phase).

IMO, this isn't a problem for dependencies because I much prefer Jam's simple approach. But there are times when I've wanted to do something similar. For example, I use autoconf with Jam and have the following:

rule ConfigJam { # # ConfigJam CONFIG.JAM : CONFIG.JAM.IN ; # # Update and include the (configure generated) Jam configuration, # usually config.jam. #

DEPENDS $(<) : $(>) ; SEARCH on $(>) = $(SEARCH_CONFIG) $(SEARCH_SOURCE) ; UpdateConfigJam $(<) : $(CONFIG_STATUS) ; include $(<) ; }

ConfigJam config.jam : config.jam.in ;

Jam correctly updates config.jam when config.jam.in changes but it doesn't include the updated config.jam until you rerun Jam. So Jam charges ahead and updates everything according to the *wrong* configuration.

Does anyone know how to do this kind of thing?

Tim

--- Tim Writer Tim.@ftlsol.com FTL Solutions Inc. Toronto, Ontario, CANADA