|
List Info
Thread: how jam handles LinkLibrary and SubInclude ?
|
|
| how jam handles LinkLibrary and
SubInclude ? |
|
2006-07-23 05:58:00 |
|
The only solution for this that I found was to make a new rule, such as this one:
# run with -sVERBOSE=1 to see messages
rule SubIncludeOnce # SubIncludeOnce TOP mylib ;
{
local includepath = [ FDirName $(<[2-]) ] ;
local path = $(includepath:R=$($(<[1]))) ;
#ECHO varname: $(path)-subinclude ;
if ! $($(path)-subinclude)
{
# not included before, so do it now.
$(path)-subinclude = TRUE ;
if $(VERBOSE)
{
ECHO "SubInclude: including" $(JAMFILE =$(path)) ;
}
include $(JAMFILE=$(path)) ;
}
else
{
if $(VERBOSE)
{
ECHO "SubInclude: already included" $(JAMFILE=$(path)) ;
}
}
}
It basically sets a flag to make sure the "SubInclude"; only happens once, and thus your code only gets built once.
-John
On 7/22/06, Groleo Marius <gmail.com">groleo gmail.com> wrote:
Hi,
Hi. I have the following directory structure:
--------------------------
Jamfile Jamrules ;lib main.cpp
groleocucu:~/test/lib$ ls -lR
.:
total 8
drwxr-xr-x 2 groleo groleo 4096 2006-07-23 01:09 dir1
drwxr-xr-x 2 groleo groleo 4096 2006-07-23 01:09 dir2
./dir1:
total 16
-rw-r--r-- 1 groleo groleo 73 2006-07-23 01:01 dir1.cpp
-rw-r--r-- 1 groleo groleo 157 2006-07-23 01:05 Jamfile
-rw-r--r-- 1 groleo groleo 84 2006-07-23 01:01
prot.h
-rw-r--r-- 1 groleo groleo 169 2006-07-23 01:07 t_dir1.cpp
./dir2:
total 16
-rw-r--r-- 1 groleo groleo 73 2006-07-23 01:01 dir2.cpp
-rw-r--r-- 1 groleo groleo 191 2006-07-23 01:03 Jamfile
-rw-r--r-- 1 groleo groleo 84 2006-07-23 01:01
prot.h
-rw-r--r-- 1 groleo groleo 214 2006-07-23 01:07 t_dir2.cpp
If I run jam, in the TOPDIR, then the library gets builded
each time a jamfile is sourced via SubInclude:
------------------
LINUX
Linux BUILD
...found 92 target(s)...
...updating 10 target(s)...
C++ lib/dir1/dir1.o
C++ lib/dir1/dir1.o
Archive lib/dir1/libdir1.a
ar: creating lib/dir1/libdir1.a
Ranlib lib/dir1/libdir1.a
C++ lib/dir2/dir2.o
Archive lib/dir2/libdir2.a
ar: creating lib/dir2/libdir2.a
Ranlib lib/dir2/libdir2.a
C++ main.o
Link main
Chmod1 main
C++ lib/dir1/t_dir1.o
C++ lib/dir1/t_dir1.o
Link lib/dir1/t_dir1
Chmod1 lib/dir1/t_dir1
Link lib/dir1/t_dir1
Chmod1 lib/dir1/t_dir1
C++ lib/dir2/t_dir2.o
Link lib/dir2/t_dir2
Chmod1 lib/dir2/t_dir2
...updated 10 target(s)...
-----------------------
How can i tell Jam to build each object/target only once ?
I have attached a directory structure simmilar to one I use in a project.
--
Regards, Groleo!
_______________________________________________
jamming mailing list - perforce.com">
jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
|
| how jam handles LinkLibrary and
SubInclude ? |
|
2006-07-23 07:59:23 |
On 7/23/06, John Waugh <john.waughgmail.com> wrote:
> The only solution for this that I found was to make a
new rule, such as this
> one:
>
> # run with -sVERBOSE=1 to see messages
> rule SubIncludeOnce # SubIncludeOnce TOP mylib ;
> {
> local includepath = [ FDirName $(<[2-]) ] ;
> local path = $(includepath:R=$($(<[1]))) ;
>
> #ECHO varname: $(path)-subinclude ;
>
> if ! $($(path)-subinclude)
> {
> # not included before, so do it now.
>
> $(path)-subinclude = TRUE ;
>
> if $(VERBOSE)
> {
> ECHO "SubInclude: including"
$(JAMFILE=$(path)
) ;
> }
>
> include $(JAMFILE=$(path)
) ;
> }
> else
> {
> if $(VERBOSE)
> {
> ECHO "SubInclude: already
included" $(JAMFILE=$(path)
) ;
> }
> }
> }
>
> It basically sets a flag to make sure the
"SubInclude" only happens once,
> and thus your code only gets built once.
>
> -John
But why would anyone would want SubInclude to build the
allready builded
file ? What's the point here ?
--
Regards, Groleo!
_______________________________________________
jamming mailing list - jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
|
|
| how jam handles LinkLibrary and
SubInclude ? |
|
2006-07-23 16:14:01 |
On 2006-07-23 at 09:59:23 [+0200], Groleo Marius
<groleogmail.com> wrote:
> On 7/23/06, John Waugh <john.waughgmail.com> wrote:
> > The only solution for this that I found was to
make a new rule, such as
> > this
> > one:
[...]
> > It basically sets a flag to make sure the
"SubInclude" only happens once,
> > and thus your code only gets built once.
>
> But why would anyone would want SubInclude to build the
allready builded
> file ? What's the point here ?
The point is that you can attach more than one action to a
target. The
actions are executed in order of their addition. Including
the Jamfile twice
causes all actions therein to be attached twice.
I suppose the only reason for you to include lib/dir1 in
lib/dir2 is that
you want to be able to cd into lib/dir2 and jam there. The
Haiku project
(http://de
veloper.berlios.de/projects/haiku/) has a slightly
modified jam
version (http://svn.berlios.de/viewcvs/haiku/buildtools/trunk/ja
m/) that
does always parse the whole Jamfile tree of the project.
Since it creates
the dependencies to the pseudotargets (all, lib, exe, files,
obj,...) only
for the targets defined in descendant dirs of the working
directory jam has
been invoked from, a "jam all" in a subdirectory
still works as expected
with the improvement that all of the project's target are
known and all
dependencies are updated correctly too.
CU, Ingo
PS: You don't need to set TOP. The first SubDir does that
for you. It is
necessary to set TOP only in case one of your tools needs
absolute paths.
And then you set the TOP as an environment var outside of
jam.
_______________________________________________
jamming mailing list - jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
|
|
| how jam handles LinkLibrary and
SubInclude ? |
|
2006-07-23 17:11:15 |
On 7/23/06, Ingo Weinhold <bonefishcs.tu-berlin.de> wrote:
>
> On 2006-07-23 at 09:59:23 [+0200], Groleo Marius
<groleogmail.com> wrote:
> > On 7/23/06, John Waugh <john.waughgmail.com> wrote:
> > > The only solution for this that I found was
to make a new rule, such as
> > > this
> > > one:
> [...]
> > > It basically sets a flag to make sure the
"SubInclude" only happens once,
> > > and thus your code only gets built once.
> >
> > But why would anyone would want SubInclude to
build the allready builded
> > file ? What's the point here ?
>
> The point is that you can attach more than one action
to a target. The
> actions are executed in order of their addition.
Including the Jamfile twice
> causes all actions therein to be attached twice.
>
> I suppose the only reason for you to include lib/dir1
in lib/dir2 is that
> you want to be able to cd into lib/dir2 and jam there.
If I would not include lib/dir1 in lib/dir2, then when I
`jam` in lib/dir2,
the libdir1 would be unknown to jam.
The Haiku project
> (http://de
veloper.berlios.de/projects/haiku/) has a slightly
modified jam
> version (http://svn.berlios.de/viewcvs/haiku/buildtools/trunk/ja
m/) that
> does always parse the whole Jamfile tree of the
project. Since it creates
> the dependencies to the pseudotargets (all, lib, exe,
files, obj,...) only
> for the targets defined in descendant dirs of the
working directory jam has
> been invoked from, a "jam all" in a
subdirectory still works as expected
> with the improvement that all of the project's target
are known and all
> dependencies are updated correctly too.
Lately i see some pathces on the list, and other mail-list
subscribers pointing
to other flavors of jam. mostly retorically i wodner why jam
doesn't include
those patches/features ?
>
> CU, Ingo
>
> PS: You don't need to set TOP. The first SubDir does
that for you. It is
> necessary to set TOP only in case one of your tools
needs absolute paths.
> And then you set the TOP as an environment var outside
of jam.
> _______________________________________________
> jamming mailing list - jammingperforce.com
> http://maillist.perforce.com/mailman/listinfo/jamming
>
--
Regards, Groleo!
_______________________________________________
jamming mailing list - jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
|
|
| how jam handles LinkLibrary and
SubInclude ? |
|
2006-07-24 15:53:47 |
On 2006-07-23 at 19:11:15 [+0200], Groleo Marius
<groleogmail.com> wrote:
> On 7/23/06, Ingo Weinhold <bonefishcs.tu-berlin.de> wrote:
[...]
> > I suppose the only reason for you to include
lib/dir1 in lib/dir2 is that
> > you want to be able to cd into lib/dir2 and jam
there.
>
> If I would not include lib/dir1 in lib/dir2, then when
I `jam` in lib/dir2,
> the libdir1 would be unknown to jam.
Yep, that's what I mean.
> The Haiku project
> > (http://de
veloper.berlios.de/projects/haiku/) has a slightly
modified jam
> > version (http://svn.berlios.de/viewcvs/haiku/buildtools/trunk/ja
m/) that
> > does always parse the whole Jamfile tree of the
project. Since it creates
> > the dependencies to the pseudotargets (all, lib,
exe, files, obj,...) only
> > for the targets defined in descendant dirs of the
working directory jam
> > has
> > been invoked from, a "jam all" in a
subdirectory still works as expected
> > with the improvement that all of the project's
target are known and all
> > dependencies are updated correctly too.
>
> Lately i see some pathces on the list, and other
mail-list subscribers
> pointing
> to other flavors of jam. mostly retorically i wodner
why jam doesn't include
> those patches/features ?
Because Perforce jam is virtually dead. There used to be a
time when the
maintainer was active on this list and a new version was
released from time
to time. But this hasn't been the case for years.
CU, Ingo
_______________________________________________
jamming mailing list - jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming
|
|
[1-5]
|
|