Re: Dealing with non-unique target names

I just stick a rule "ConfigureBuild" in Jamrules and call that after
every call to SubDir.

Matt Doar <matt <at> trpz.com> writes:

> We ended up putting
>
> LOCATE_TARGET = $(BUILD_DIR)/$(SUBDIR_TOKENS:J=/) ;
>
> at the top of all our Jamfiles.
>
> ~Matt
>
>
> On Wed, 2003-03-19 at 05:21, Ingo Weinhold wrote:
>> On Wed, 19 Mar 2003, Jacob Gorm Hansen wrote:
>> 
>> > Hi,
>> >
>> > I would like my temporary object-files to end up in a structure similar
>> > to that of my source tree, or alternatively with all files prefixed
>> > grist-like.
>> >
>> > Is this possible to achieve from Jamrules, or do I need to modify each
>> > and every Jamfile in my project?
>> 
>> Good question. I don't know any, that doesn't involve a significant amount
>> of hacking.
>> 
>> It would be great, if an empty UserSubDir rule (similar to UserObject)

Re: Dealing with non-unique target names

On Tue, 2003-04-01 at 07:36, Matt Armstrong wrote:
> I just stick a rule "ConfigureBuild" in Jamrules and call that after
> every call to SubDir.

Thanks for your input. I ended up modifying MakeLocate in Jambase to
better fit my needs.

best,
Jacob

EOL match in egrep expression?

RE: EOL match in egrep expression?

different rules for textfiles

Hi,

I've got a couple of files that all have a .txt extension, and create header 
files, but by separate programs. I wonder how to set up the rules for this, 
seems like I can't use UserObject for this.

A.txt runs through X.sh to produce A.h
B.txt runs through Y.sh to produce B.h

etc.

I'm pretty new to jam (started playing with it yesterday), and I've got all 
the obvious stuff (and some not-so-obvious) from our Makefiles converted to 
jam. But this one thing I haven't been able to figure out.

Enno.

Re: different rules for textfiles

Okay, getting a bit late, I've answered my previous question...

However, I'm sure there's a more elegant solution. I added the following to 
my Jamrules:

   actions IdCompile
   {
     perl $(TOP)/tools/create_enum_file $(>) > $(<)
   }

   rule IdFile
   {
     Depends $(<) : $(>) ;
     IdCompile $(<) : $(>) ;
   }

which handles one type of  textfiles I have. I then added this to the 
Jamfile in one of my project's subdirectories:

   IdFile TypeID.h : $(SUBDIR)/Setupfiles/TypeID.txt ;
   IdFile RDBID.h : $(SUBDIR)/Setupfiles/RDBID.txt ;

Writing $(SUBDIR)/Setupfiles/ looks kind of ugly, but I haven't found a more 
elegant-looking way (especially adding the directory to SEARCH_SOURCE didn't 
work).

Enno.

recompiles

I've got some trouble with unnecessary recompiles. My Jamfile looks like this:
---- Jamfile start
SOURCES =
# more.cpp
  main.cpp ;

Main test : $(SOURCES) ;
---- Jamfile end
The weird thing here is, when I remove the # to add one more source to 
$(SOURCES), I was expecting jam to only compile that one sourcefile and 
re-link. However, it insists on recompiling some (not all) of the files in 
$(SOURCES). However, it doesn't insist on it if I'm simply adding the new 
file to the *end* of the list of sources. Why is that?

All my files are essentially empty. The problem seems to be connected to the 
fact that they include a common header file (which itself simply includes 
stdio.h). However, I don't see why that creates any dependencies?

Here are the files:

---- more.cpp begin
#include "Utils.h"
---- more.cpp end

--- main.cpp begin
#include "Utils.h"
int main(int, char**) { return 0; }
--- main.cpp end

--- Utils.h begin
#include <stdio.h>
--- Utils.h end

Any ideas? Seriously puzzled by this, I am.

Enno.

Re: recompiles

I've reduced the problem to an even smaller example (removed the header). I 
now have two files that both include <features.h> and nothing else. When I 
add more.cpp to my sources list, I get the following output for jam -dmda -n 
(and as you can see, it still wants to recompile main.cpp). I'm afraid I 
can't really read the output of jam so well, but none of the header files 
seems to have been touched, so why does it say:
   made*   newer           gnu/stubs.h

Here's the full output:

make    --      all
time    --      all: unbound
Depends "all" : "shell" ;
make    --       shell
time    --       shell: unbound
Depends "shell" : "first" ;
make    --        first
time    --        first: unbound
made    stable    first
made    stable   shell
Depends "all" : "files" ;
make    --       files
time    --       files: unbound
Depends "files" : "first" ;
made    stable   files
Depends "all" : "lib" ;
make    --       lib
time    --       lib: unbound
Depends "lib" : "first" ;
made    stable   lib
Depends "all" : "exe" ;
make    --       exe
time    --       exe: unbound
Depends "exe" : "first" ;
Depends "exe" : "test" ;
make    --        test
time    --        test: Wed Apr  2 15:02:08 2003
Depends "test" : "more.o" ;
make    --         more.o
time    --         more.o: missing
Depends "more.o" : "more.cpp" ;
make    --          more.cpp
time    --          more.cpp: Wed Apr  2 15:00:57 2003
make    --           more.cpp
time    --           more.cpp: parents
Includes "more.cpp" : "features.h" ;
make    --            features.h
bind    --            features.h: /usr/include/features.h
time    --            features.h: Tue Feb 25 14:43:59 2003
make    --             features.h
time    --             features.h: parents
Includes "features.h" : "sys/cdefs.h" ;
make    --              sys/cdefs.h
bind    --              sys/cdefs.h: /usr/include/sys/cdefs.h
time    --              sys/cdefs.h: Tue Feb 25 14:45:29 2003
make    --               sys/cdefs.h
time    --               sys/cdefs.h: parents
Includes "sys/cdefs.h" : "features.h" ;
made*   newer           sys/cdefs.h
Includes "features.h" : "gnu/stubs.h" ;
make    --              gnu/stubs.h
bind    --              gnu/stubs.h: /usr/include/gnu/stubs.h
time    --              gnu/stubs.h: Tue Feb 25 14:46:39 2003
made*   newer           gnu/stubs.h
made*   newer         features.h
made*   newer       more.cpp
made+   update     more.o
Depends "test" : "main.o" ;
make    --         main.o
time    --         main.o: Wed Apr  2 15:02:08 2003
Depends "main.o" : "main.cpp" ;
make    --          main.cpp
time    --          main.cpp: Wed Apr  2 15:02:03 2003
make    --           main.cpp
time    --           main.cpp: parents
Includes "main.cpp" : "features.h" ;
made    stable      main.cpp
made+   update     main.o
made+   update    test
made    update   exe
Depends "all" : "obj" ;
make    --       obj
time    --       obj: unbound
Depends "obj" : "first" ;
Depends "obj" : "more.o" ;
Depends "obj" : "main.o" ;
made    update   obj
Depends "all" : "first" ;
made    update  all
...found 15 target(s)...
...updating 3 target(s)...
C++ more.o
C++ main.o
Link test
Chmod1 test
...updated 3 target(s)...

Enno

SubDirHdrs question

Hi,

I've just started using jam, version 2.4 under Linux.

I've succesfully made a couple of Jamfiles that build a library in a
subdirectory and build an executable in the top directory that is linked
with the library, but I've had to use the SubDirHdrs rule in a strange
(counter-intuitive) way. Perhaps I'm just not understanding the SubDir and
SubInclude rules? This is the structure of my test project:

Jamfile
support.cpp
animtable.cpp
xmlparser.cpp
expat_config.h
...
xmllib/
      Jamfile
      xmltok.c
      xmlparse.c
      xmlrole.c
      ...

The files in xmllib/ are compiled to produce a library (libexpat.a) in that
directory, which the executable (animtable) in the top directory is linked
with.

Jamfile contains this:
-----------------------------
SubDir TOP ;
LINKLIBS = -lstdc++ -lg ;
Main animtable : support.cpp animtable.cpp xmlelement.cpp xmlparser.cpp ;
LinkLibraries animtable : libexpat ;

SubInclude TOP xmllib ;
-----------------------------

And xmllib/Jamfile looks like this:

-----------------------------
SubDir TOP xmllib ;
SubDirHdrs . ;
Library libexpat : xmlparse.c xmltok.c xmlrole.c ;
-----------------------------

The .c files in xmllib/ contain #include "expat_config", which is actually
in the directory above. In order to get the compiler to find
expat_config.h, I've added the SubDirHdrs rule. What I don't fully
understand, or rather, what I find odd, is the fact that I have to set it
to '.' After all, the header being searched for isn't _in_ the directory
that the Jamfile is in (xmllib), it's in the directory above - '..'
Someone reading xmllib/Jamfile will assume I'm talking about the xmllib
directory!

From examining the commands Jam invokes, I can see that it actually calls
'cc' from the top directory on the .c files in xmllib/ :

cc  -c -o xmllib/xmlparse.o  -O   -Ixmllib -I.  xmllib/xmlparse.c

hence the reason that the -I. needs to be passed to the compiler.

So, what am I misunderstanding, or what am I doing wrong? I just think this
setup is odd. I realise that I could just move expat_config.h into xmllib/,
but that's no fun 

Thanks,

Paul

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
postmaster <at> scee.net

This footnote also confirms that this email message has been checked
for all known viruses.

**********************************************************************
 SCEE 2003

Re: SubDirHdrs question

Enno Rehling wrote:
>Paul_Donovan <at> scee.net wrote:
>> The .c files in xmllib/ contain #include "expat_config", which is
actually
>> in the directory above. In order to get the compiler to find
>> expat_config.h, I've added the SubDirHdrs rule. What I don't fully
>> understand, or rather, what I find odd, is the fact that I have to set
it
>> to '.' After all, the header being searched for isn't _in_ the directory
>> that the Jamfile is in (xmllib), it's in the directory above - '..'
>> Someone reading xmllib/Jamfile will assume I'm talking about the xmllib
>> directory!
>
>But jam is calling the compiler from the directory below, and if it called

>it with -I.., it would be looking in the wrong place. I think the right
>thing to do there is to write:
>   SubDirHdrs $(SUBDIR)/.. ;
>That way, you can also call jam from the xmllib/ subdirectory, because the

>path for -I will be correct at all times.

Thanks Enno, that works a treat! As you say, I can now call jam from either
directory. I'll leave working out how it works until tomorrow - I can only
learn so much in one day 

[Ah, Funcom - same line of work as me then  ]

Paul

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
postmaster <at> scee.net

This footnote also confirms that this email message has been checked
for all known viruses.

**********************************************************************
 SCEE 2003