2 Jul 2002 23:23
4 Jul 2002 15:33
RE: layering and code generation
Chris Higgins <chris.higgins <at> cursor-system.com>
2002-07-04 13:33:35 GMT
2002-07-04 13:33:35 GMT
>-----Original Message-----
>From: Diane Holt [mailto:holtdl <at> yahoo.com]
>Sent: Thursday, May 16, 2002 12:17 AM
>To: jamming <at> perforce.com
>Subject: Re: [jamming] layering and code generation
>
>
>--- Tim Baker <dbaker <at> direct.ca> wrote:
>> Maybe this will work:
>>
>> DEPENDS layer4 : layer3 ;
>> DEPENDS layer3 : layer2 ;
>> DEPENDS layer2 : layer 1 ;
>> NOTFILE layer1 layer2 layer3 layer4 ;
>>
>> rule L1Main
>> {
>> Main $(<) : $(>) ;
>> DEPENDS layer1 : $(<) ;
>> }
>> rule L1Library
>> {
>> Library $(<) : $(>) ;
>> DEPENDS layer1 : $(<) ;
>> }
>[snip]
>
>Yeah, that was the other way I thought of that I ended up not
>going down,
>since it involves more work than just what you've shown here -- because
>once you hit the Main and Library rules, you're back to hitting
>dependencies on the "lib" and "exe" pseudo-targets, which are
>dependencies
>of "all", so you're back to Jam building all the libraries (in all the
>layers) then all the exes. IOW, you'd need to go a lot further down the
>road of creating new rules and pseudo-targets to distinguish
>the targets
>being built for each layer (and, like I said, that was more than I felt
>like doing for free :)
I gave up on this for a while but came back to it after an idea that is
similar to what Diane is saying at the end here but not much work at all.
The key is being prepared to override jambase rules but the changes are
trivial and (I believe) backwards compatable.
To my jamrules I add
shell_t ?= shell ;
files_t ?= files ;
lib_t ?= lib ;
exe_t ?= exe ;
obj_t ?= obj ;
first_t ?= first ;
Now I replace any uses of these standard pseudotargets with their variable
counterparts. So for example Objects becomes
rule Objects
{
local _i ;
for _i in [ FGristFiles $(<) ]
{
Object $(_i:S=$(SUFOBJ)) : $(_i) ;
Depends $(obj_t) : $(_i:S=$(SUBFOBJ)) ;
}
}
(apologies for any typos, consult your jambase).
Now string the layers together:
rule MkLayers
{
if $(<)
{
Layer $(<[1]) ;
Layers $(<[1]) : $(<[2-]) ;
}
}
rule Layer
{
first_t = $(<)first_t ;
shell_t = $(<)shell_t ;
obj_t = $(<)obj_t ;
files_t = $(<)files_t ;
lib_t = $(<)lib_t ;
exe_t = $(<)exe_t ;
Depends all : $(first_t) $(shell_t) $(obj_t) $(files_t) $(lib_t) $(exe_t)
;
Depends all $(shell_t) $(obj_t) $(files_t) $(lib_t) $(exe_t) : $(first_t)
;
NotFile $(first_t) $(shell_t) $(obj_t) $(files_t) $(lib_t) $(exe_t) ;
SubInclude LAYER_TOP $(<) ;
}
rule Layers
{
if $(>)
{
Depends $(>[1])first_t : $(<)exe_t ;
Layer $(>[1]) ;
Layers $(>[1]) : $(>[2-]) ;
}
}
In your topmost Jamfile write MkLayers a b c. It only works at the top-level
because of that SubInclude, bit more work to try to generalise that.
So, the idea is that each layer dances to its own set of pseudo-targets and
layers are placed on top of each other last-of-one to first-of-next.
This seems to do what I want, but its not well-tested yet. Can any more
experienced jammers spot gotchas?
thanks, chris
This email is subject to the disclaimer set out below
*****************************************************
THIS E-MAIL MAY CONTAIN INFORMATION THAT IS CONFIDENTIAL AND/OR LEGALLY
PRIVILEGED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DO NOT READ IT,
DELETE IT IMMEDIATELY AND INFORM CAMBRIDGE POSITIONING SYSTEMS LIMITED BY
TELEPHONING +44 (0)1223 326900.
This Email has been checked for viruses but it is your responsibility to
conduct your own virus checks on all parts of it.
Cambridge Positioning Systems Limited, 62-64 Hills Road, Cambridge, CB2 1LA,
is registered in England under company number 2808344.
***************************************************************************
9 Jul 2002 02:14
LOCATE bug in Jam 2.4?
Chris Rumpf <Chris.Rumpf <at> calix.com>
2002-07-09 00:14:17 GMT
2002-07-09 00:14:17 GMT
===================================================
Does the LOCATE variable leak - or perhaps it's the "on" operator?
In the below example why does Jam add the binding of c.yy to a.x?
Let me explain:
I simply want to set the LOCATE variable on c.yy ONLY.
I can't figure out how to do that. Jam is also putting the
binding on a.x (see below)
I use the "LOCATE on" operator - then print out the values of
the LOCATE variable for each target. It looks great UNTIL
the action is executed when magically the binding has happened
on a.x.
Can anyone explain to me what is going on here?
Am I doing something wrong here?
Thanks in advance for any help.....
===================================================
:-> cat Jamfile
SubDir TOP a src ;
rule see {
return $(1) ;
}
rule r1 {
LOCATE on c.yy = /home1/crumpf/abc ;
}
actions r1 {
/bin/cp $(2) $(1)
}
a1 = [ on c.yy see $(LOCATE) ] ;
a2 = [ on a.x see $(LOCATE) ] ;
Echo ====== a1 $(a1) ;
Echo ====== a2 $(a2) ;
r1 c.yy : a.x ;
:->
:->
:->
:->
:-> jam c.yy
Environment: gcc - solaris2
====== a1 /home1/crumpf/abc
====== a2
...found 1 target(s)...
...updating 1 target(s)...
warning: using independent target a.x
r1 /home1/crumpf/abc/c.yy
cp: cannot access /home1/crumpf/abc/a.x
/bin/cp /home1/crumpf/abc/a.x /home1/crumpf/abc/c.yy
...failed r1 /home1/crumpf/abc/c.yy ...
...failed updating 1 target(s)...
:->
I expect this action line to look like
/bin/cp a.x /home1/crumpf/abc/c.yy
Am I wrong in my assumption?
/* ---
Christopher M. Rumpf
Cube #170
--- */
9 Jul 2002 14:40
Re: LOCATE bug in Jam 2.4?
Ingo Weinhold <bonefish <at> cs.tu-berlin.de>
2002-07-09 12:40:54 GMT
2002-07-09 12:40:54 GMT
> ===================================================
>
> :-> cat Jamfile
> SubDir TOP a src ;
>
> rule see {
> return $(1) ;
> }
>
> rule r1 {
> LOCATE on c.yy = /home1/crumpf/abc ;
> }
>
> actions r1 {
> /bin/cp $(2) $(1)
> }
>
> a1 = [ on c.yy see $(LOCATE) ] ;
> a2 = [ on a.x see $(LOCATE) ] ;
>
> Echo ====== a1 $(a1) ;
> Echo ====== a2 $(a2) ;
>
> r1 c.yy : a.x ;
>
> :->
> :->
> :->
> :->
> :-> jam c.yy
> Environment: gcc - solaris2
> ====== a1 /home1/crumpf/abc
> ====== a2
That is strange. You must have set LOCATE on c.yy somewhere else,
because r1 is invoked _after_ you look up the value.
> ...found 1 target(s)...
> ...updating 1 target(s)...
> warning: using independent target a.x
> r1 /home1/crumpf/abc/c.yy
> cp: cannot access /home1/crumpf/abc/a.x
>
> /bin/cp /home1/crumpf/abc/a.x /home1/crumpf/abc/c.yy
>
> ...failed r1 /home1/crumpf/abc/c.yy ...
> ...failed updating 1 target(s)...
> :->
>
>
> I expect this action line to look like
> /bin/cp a.x /home1/crumpf/abc/c.yy
>
> Am I wrong in my assumption?
In doubt consider this a feature, not a bug. 
I didn't have a look into the source code, but it seems that the LOCATE
variable of a target is used for independent source targets with an
empty LOCATE as well. Just add the missing dependency (jam warns you
about it) in rule r1:
rule r1 {
LOCATE on $(1) = /home1/crumpf/abc ;
DEPENDS $(1) : $(2) ;
}
CU, Ingo
22 Jul 2002 16:51
Problem: Directory with same name as target creates directory wit h same name as target
Roger Lipscombe <RLipscombe <at> sonicblue.com>
2002-07-22 14:51:49 GMT
2002-07-22 14:51:49 GMT
I've got a directory with the same name as the target to be generated in that directory. This doesn't seem to work. What am I doing wrong? $ ls Jamfile foo/ $ ls foo Jamfile foo1.cpp foo1.h foo2.cpp foo2.h $ cat Jamfile SubDir TOP ; SubInclude TOP foo ; $ cat foo/Jamfile SubDir TOP foo ; Main foo : foo1.cpp foo2.cpp ; I get: $ jam Jamrules: No such file or directory warning: foo depends on itself warning: foo depends on itself warning: foo depends on itself ...found 14 target(s)... ...updating 3 target(s)... C++ foo/foo1.o C++ foo/foo2.o MkDir1 foo/foo Link foo/foo /usr/bin/ld: cannot open output file foo/foo: Is a directory collect2: ld returned 1 exit status cc -o foo/foo foo/foo1.o foo/foo2.o ...failed Link foo/foo ... ...failed updating 1 target(s)... ...updated 2 target(s)... $ jam clean Jamrules: No such file or directory ...found 1 target(s)... ...updating 1 target(s)... Clean clean rm: `foo/foo' is a directory rm -f foo/foo foo/foo1.o foo/foo2.o ...failed Clean clean ... ...failed updating 1 target(s)... The Jamrules line is harmless, I know. The question is: why the MkDir1 foo/foo? Am I allowed to do this kind of thing? Cheers, Roger.
22 Jul 2002 17:12
Re: Problem: Directory with same name as target creates directory wit h same name as target
Dave Lewis <dlewis <at> vignette.com>
2002-07-22 15:12:44 GMT
2002-07-22 15:12:44 GMT
the easy fix it to not name them the same. there is a bug in the mkdir target (perhaps a feature) that makes the directory to be made a target name, thus it conflicts with the other target of the same name. dave > From: Roger Lipscombe <RLipscombe <at> sonicblue.com> > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2653.19) > Content-Type: text/plain; > charset="iso-8859-1" > Sender: jamming-admin <at> perforce.com > Errors-To: jamming-admin <at> perforce.com > X-BeenThere: jamming <at> perforce.com > X-Mailman-Version: 2.0.4 > Precedence: bulk > List-Help: <mailto:jamming-request <at> perforce.com?subject=help> > List-Post: <mailto:jamming <at> perforce.com> > List-Subscribe: <http://maillist.perforce.com/mailman/listinfo/jamming>, > <mailto:jamming-request <at> perforce.com?subject=subscribe> > List-Id: Discuss the build tool Jam/MR with other users <jamming.perforce.com> > List-Unsubscribe: <http://maillist.perforce.com/mailman/listinfo/jamming>, > <mailto:jamming-request <at> perforce.com?subject=unsubscribe> > List-Archive: <http://maillist.perforce.com/pipermail/jamming/> > Date: Mon, 22 Jul 2002 07:51:49 -0700 > > I've got a directory with the same name as the target to be generated in > that directory. This doesn't seem to work. > What am I doing wrong? > > $ ls > Jamfile foo/ > $ ls foo > Jamfile foo1.cpp foo1.h foo2.cpp foo2.h > $ cat Jamfile > SubDir TOP ; > > SubInclude TOP foo ; > > $ cat foo/Jamfile > SubDir TOP foo ; > > Main foo : foo1.cpp foo2.cpp ; > > I get: > > $ jam > Jamrules: No such file or directory > warning: foo depends on itself > warning: foo depends on itself > warning: foo depends on itself > ...found 14 target(s)... > ...updating 3 target(s)... > C++ foo/foo1.o > C++ foo/foo2.o > MkDir1 foo/foo > Link foo/foo > /usr/bin/ld: cannot open output file foo/foo: Is a directory > collect2: ld returned 1 exit status > > cc -o foo/foo foo/foo1.o foo/foo2.o > > ...failed Link foo/foo ... > ...failed updating 1 target(s)... > ...updated 2 target(s)... > > $ jam clean > Jamrules: No such file or directory > ...found 1 target(s)... > ...updating 1 target(s)... > Clean clean > rm: `foo/foo' is a directory > > rm -f foo/foo foo/foo1.o foo/foo2.o > > ...failed Clean clean ... > ...failed updating 1 target(s)... > > The Jamrules line is harmless, I know. The question is: why the MkDir1 > foo/foo? Am I allowed to do this kind of thing? > > Cheers, > Roger. > _______________________________________________ > jamming mailing list - jamming <at> perforce.com > http://maillist.perforce.com/mailman/listinfo/jamming >
22 Jul 2002 17:43
RE: Problem: Directory with same name as target creates directory wit h same name as target
Roger Lipscombe <RLipscombe <at> sonicblue.com>
2002-07-22 15:43:22 GMT
2002-07-22 15:43:22 GMT
> the easy fix it to not name them the same. there is a bug > in the mkdir target (perhaps a feature) that makes the > directory to be made a target name, thus it conflicts with > the other target of the same name. OK. So what's the hard fix? I want them to have the same name. Moreover, I'm not calling MkDir anywhere, so what's going on? Cheers, Roger.
22 Jul 2002 17:43
Re: Problem: Directory with same name as target creates directory wit h same name as target
Ingo Weinhold <bonefish <at> cs.tu-berlin.de>
2002-07-22 15:43:25 GMT
2002-07-22 15:43:25 GMT
On Mon, 22 Jul 2002, Roger Lipscombe wrote: > I've got a directory with the same name as the target to be generated in > that directory. This doesn't seem to work. > What am I doing wrong? > > $ ls > Jamfile foo/ > $ ls foo > Jamfile foo1.cpp foo1.h foo2.cpp foo2.h > $ cat Jamfile > SubDir TOP ; > > SubInclude TOP foo ; > > $ cat foo/Jamfile > SubDir TOP foo ; > > Main foo : foo1.cpp foo2.cpp ; To avoid the name clash explicitly add grist: Main <$(SOURCE_GRIST)>foo : foo1.cpp foo2.cpp ; > I get: [...] > The Jamrules line is harmless, I know. The question is: why the MkDir1 > foo/foo? Am I allowed to do this kind of thing? The reason for that is the line MakeLocate $(_t) : $(LOCATE_TARGET) ; in the MainFromObjects rule. After variable expansion it reads MakeLocate foo : foo ; Which in theory is absolutely correct as the executable `foo' should be located in directory `foo', but the name clash causes trouble: MakeLocate in turn sets LOCATE on `foo' to `foo', makes `foo' depend on `foo' and does a `MkDir foo'. Due to the LOCATE value the directory target `foo' is bound to `foo/foo' (as is the executable `foo'). It doesn't exist yet and therefore MkDir1 is invoked to make it. Adding grist to the identifier of the executable target makes the two targets syntactically different and thus avoids the cyclic dependency as well as setting of LOCATE on the wrong target (too). CU, Ingo
22 Jul 2002 17:51
Re: Problem: Directory with same name as target creates directory wit h same name as target
Diane Holt <holtdl <at> yahoo.com>
2002-07-22 15:51:50 GMT
2002-07-22 15:51:50 GMT
--- Dave Lewis <dlewis <at> vignette.com> wrote: > the easy fix it to not name them the same. there is a bug > in the mkdir target (perhaps a feature) that makes the > directory to be made a target name, thus it conflicts with > the other target of the same name. You'll be happy to know this looks to be getting addressed in Jam 2.5. The change description for change 1904: Internal Perforce jam changes. See RELNOTES for details, but they're: 1. MkDir grists dir names so as not to conflict with other targets. 2. SubDir reworked to allow multiple, cooperating trees. 3. Makefile now uses $(EXENAME) so that . doesn't need to be in the user's path. These changes are bound for jam 2.5. See the change details at: http://www.rawbw.com/~dianeh/cgi-bin/p4db/chv.cgi?CH=1904 Diane ===== (holtdl <at> yahoo.com) __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
22 Jul 2002 18:25
Re: Problem: Directory with same name as target creates directory wit h same name as target
Ingo Weinhold <bonefish <at> cs.tu-berlin.de>
2002-07-22 16:25:20 GMT
2002-07-22 16:25:20 GMT
On Mon, 22 Jul 2002, Diane Holt wrote: > You'll be happy to know this looks to be getting addressed in Jam 2.5. The > change description for change 1904: > Internal Perforce jam changes. See RELNOTES for details, > but they're: > 1. MkDir grists dir names so as not to conflict > with other targets. > 2. SubDir reworked to allow multiple, cooperating > trees. > 3. Makefile now uses $(EXENAME) so that . doesn't > need to be in the user's path. > These changes are bound for jam 2.5. > > See the change details at: > http://www.rawbw.com/~dianeh/cgi-bin/p4db/chv.cgi?CH=1904 Nice. I wonder, what is the right procedure for suggesting changes. I have a some patches ready -- reaching from simple adjustions to Jambase to set sane variable values for BeOS up to the addition of a rule that executes commands at parsing time (supplying their return values) and changes that make Jam always read the whole Jamfile tree regardless of in which subdirectory it is executed (nevertheless only the subtree is built) -- but I didn't dare to propose anything yet.
RSS Feed