Undesired multi pass build

I thought that I should ask the mailing list about this before getting 
lost in the jam source.  

We generate .h files based on .c files.  For example, we might have 
common.c:

        int     Answer = 42;

from which we generate a common.h in an include directory:

        extern int      Answer;

Note that common.c is used to both compile and to generate the header 
file.

Now let's say there is a source.c that does #include <common.h>.

There is a library that is built from common.c and source.c.

When I update common.c and run jam, common.h gets regenerated and common.c 
is recompiled. But source.c does not get recompiled.  I run jam again, and 
source.c gets recompiled.

Any ideas on how to fix the following Jamfile so an update of common.c 
will rebuild both common.h and compile both .c files?  If not, any hints 
on fixing this in jam?

GENINC = $(GENDIR)/include ;
HDRS += $(GENINC) ;

Re: Undesired multi pass build

That can't be done, I'm afraid. But maybe the problem can be restated so 
that the goal is achievable.

Jam's design is (simplifying):

1. Look at the files.
2. Decide what to do.
3. Do it.

Nice and simple. But it prevents you from e.g. first generating common.h 
and then deciding whether to compile source.o.

So, what can you do? One possibility is to tell jam explicitly that 
source.o depends on common.h, so that whenever jam decides to build 
common.h, it will also build source.o.

Arnt

Re: Undesired multi pass build

--- Roger.Shimada <at> lawson.com wrote:
>         LawMkHdr $(GENINC)/$(var:B).h : $(var:B).c : -g ;

I suspect this is your problem. Your header-file target isn't the same as
what source.c #include's -- HdrRule puts an Includes on source.c of
common.h, not $(GENINC)/common.h, so there's no association between
common.h the target and common.h the #include'd header file, so there's
none between common.h the target and source.c, just between source.c and
the common.h it finds in $(GENINC) (via $(HDRSEARCH)) once common.h has
been built. So there's nothing saying to rebuild source.c, until after
common.h has been built (and its timestamp bumped), which is why source.c
recompiles on a second pass but not on one. If you make your target the
same as what's #include'd, you should probably be okay.

Diane

=====
(holtdl <at> yahoo.com)

__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

.obj output dir

Re: .obj output dir

On Feb 6, 2004, at 8:10 PM, Marco Pappalardo wrote:

> 've tried LOCATE_TARGET and ALL_LOCATE_TARGET, and although 
> ALL_LOCATE_TARGET does relocate the exe, the obj are still generated 
> in the same dir as the sources. My question is what is the standard 
> way to tell Jam to output the .obj to a certain dir ? (if there is 
> any)

LOCATE_TARGET should do it.  How are you setting it?  For example, 
LOCATE_TARGET on whatever$(SUFEXE) = won't affect the intermediate 
files which built the exe.  If you have multiple subprojects, I posted 
a simple $(SUBDIRRULES) a while ago you can put in your Jamrules which 
gives you msdev-like behavior.  It sort of breaks the spirit of Jam 
(take any Jamfile project and send output anywhere without modifying 
the Jamfile), but it's probably what you want.

> Or should I just modify the c++ rule so that it /Fo's to a specific 
> dir ?

No.  The stock rules already did that for you.

How to create a directory

xxx already defined in lib, ignoring second definition

Re: xxx already defined in lib, ignoring second definition

If you build from one directory, then update one of the library's 
members and build from another directory, the object file isn't seen as 
the same object file because the paths are different.

So your updated object file is now in the library twice.  cd to where 
the library lives and jam clean.

Unlike ar, lib.exe stores the path specified on the command line of the 
object files in the resulting library.  This is a problem for us too.  
I suppose it could be solved by modifying the Library rule to be in the 
directory of the object files when updating the library, but this 
becomes a hard problem to solve when the object files are all over the 
place.

Add it to the very long list of stupid MS behaviors in their tools.  
(You should see the tricks I had to do just to get parallel builds 
working properly)

On Feb 11, 2004, at 7:26 PM, Marco Pappalardo wrote:

> warning : myfunction() already defined in mylib.lib, ignoring second 
> definition.
>  
> Am I right to assume from this message that the old code for 
> myfunction() is not being replaced by the new code for myfunction() ? 
> Any ideas on how to fix this ?

Re: xxx already defined in lib, ignoring second definition

From: "Paul Forgey" <paulf <at> metainfo.com>
> Add it to the very long list of stupid MS behaviors in their tools.
> (You should see the tricks I had to do just to get parallel builds
> working properly)

Do you use the parallel build on an SMP machine, or across different
machines? I'm interested in making this work, on MS as well.

Thanks,
Alen

Re: xxx already defined in lib, ignoring second definition

SMP.  Currently, there's no good way to distribute builds around an NT 
environment.  Maybe with gcc, and as soon as the x86 optimizations get 
better.  Unfortunately, msvc currently produces faster code.  
Effectively, the same rules apply for either SMP or distributed builds 
since they both involve multiple processes working on the same project.

There are two basic problems with msvc's default behavior that gets in 
the way of SMP builds.  Writing debug info to a common database file, 
and automatic pre-compiled headers.

For debug builds, use -Z7 -Yd to put the debug information into the 
object files (then into the dll or exe).  A separate .pdb file still 
gets generated at link time.  So far, I haven't noticed any difference 
in debugging behavior doing things this way vs. the way dev studio 
projects want do it by default.

As for pre-compiled headers, generate them ahead of time with one 
source file that simply includes what you want in your pch (like 
stdafx.cpp for vc generated mfc projects) with -Yc and use -Yu with the 
rest of your files to use it.  Set up the dependencies properly to 
avoid race conditions between the processes.  You can use -Fp to place 
the precompiled header data in $(LOCATE_TARGET).

On Feb 13, 2004, at 12:11 AM, Alen Ladavac wrote:

> From: "Paul Forgey" <paulf <at> metainfo.com>
>> Add it to the very long list of stupid MS behaviors in their tools.
>> (You should see the tricks I had to do just to get parallel builds
>> working properly)
>
> Do you use the parallel build on an SMP machine, or across different
> machines? I'm interested in making this work, on MS as well.
>
> Thanks,
> Alen
>
> _______________________________________________
> jamming mailing list  -  jamming <at> perforce.com
> http://maillist.perforce.com/mailman/listinfo/jamming