gmane.comp.tools.jam

Re: Object rule and directories

Diane Holt — 2012-10-26T01:51:24

I agree -- take the relative path out of the #include statements, then...

If you don't let Jam set HDRGRIST on the headers, you don't really
need to do much to get it to gen the headers for you:

$ cat Jamrules
rule GenHdr
{
    MakeLocate $(<) : $(LOCATE_TARGET) ;
    Clean clean : $(<) ;
}

actions GenHdr
{
    echo "int x = 10;" > $(<)
}


$ cat Jamfile
SubDir TOP ;

HDRGRIST = ;
GenHdr b.h ;
Objects b.c ;

SubInclude TOP src ;


$ cat src/Jamfile
SubDir TOP src ;

HDRGRIST = ;
GenHdr a.h  ;
GenHdr c.h  ;
Objects a.c c.c ;


$ ./jam -n -d+1
...found 22 target(s)...
...updating 6 target(s)...
GenHdr /tmp/weird/./b.h
Cc /tmp/weird/./b.o
GenHdr /tmp/weird/src/a.h
Cc /tmp/weird/src/a.o
GenHdr /tmp/weird/src/c.h
Cc /tmp/weird/src/c.o
...updated 6 target(s)...

Of course, I would never really recommend building anything out to the
source tree, so you may want to beef that all up a bit :)

Diane

On Thu, Oct 25, 2012 at 4:49 AM, Ingo Weinhold <ingo_weinhold< at >gmx.de> wrote:
_______________________________________

Re: Object rule and directories

Ingo Weinhold — 2012-10-25T11:49:14

You are right, your Jamfile provides all dependencies (though not quite in the way that things match up).

In case you haven't seen it yet, I posted an answer to your StackOverflow question. It hopefully explains things in sufficient detail. There's certainly more that can be explained, particularly regarding the use of grist.

CU, Ingo
_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Re: Object rule and directories

2012-10-25T11:05:54

Hello Sanel Zukan, thank you for your quick reply.

I didn't specify the dependency of 'all' because I wanted
to test the various build targets in isolation. The Jamfile
you provided still doesn't work when you try to invoke it
on c.o alone:

jam c.o

Which I believe should be a legitimate action. Both our
Jamfiles fail. I feel like my Jamfile already had enough
dependency details to build c.o:

First I say that c.o depends on src/c.c; the Object rule
should recognize that there is a dependency between c.o
and src/c.h by scanning the src/c.c.

    Object c.o : src/c.c ;

In addition to this, src/c.h is passed as the first argument
of an action, and hence should be considered as a build
target, and it can be built without any source target.

I'll restate the problem; I have the following directory structure:

project/
    Jamfile
    src/
        foo.c

With foo.c being:

    #include "foo.h"

    int main(int argc, char *argv[])
    {
        return 0;
    }

Question: I want to be able to cd into project an

Re: Object rule and directories

Sanel Zukan — 2012-10-25T06:03:44

Hi,

You can use SubDirHdrs rule for this. Also, you are missing dependency details,
so I'm not sure how your example compiled the files. Here is the modified, which
do the job:

--------------------------------------------
rule CreateHeader
{
   Depends all : $(1) ;
   Clean clean : $(1) ;
}

actions CreateHeader
{
   echo "int x = 10;" > $(1)
}

CreateHeader src/a.h ;
CreateHeader src/b.h ;
CreateHeader src/c.h ;

SubDirHdrs . ;

Object a.o : src/a.c ;
Object b.o : b.c ;
Object c.o : src/c.c ;

Depends all : a.o b.o c.o ;
--------------------------------------------

SubDirHdrs setup header search path, but you probably should setup a.c with
'#include "a.h"' instead '#include "src/a.h"' which feels more natural
to jam and other
build systems.

Regards,
Sanel


On Thu, Oct 25, 2012 at 6:08 AM,  <dario.damico< at >damix.it> wrote:
_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Object rule and directories

2012-10-25T04:08:02

I everybody, I have a problem in generating a header file as a result of a scanned
dependency. I initially posted my question on StackOverflow, and I'll be happy to
accept the answer if it is also posted there:

http://stackoverflow.com/questions/13045315/jam-object-rule-and-directories

I suspect that the manual is actually saying what I'm doing wrong, but I can't really
see a solution; the problem occurs when the .c file and the .o file to be build are not
in the same directory, and the .c file has a scanned dependency on a .h file which
has to be generated on the fly. The problem can be probably be solved by manually
setting dependencies between the .c and .h file, but I would like to avoid that.

I have the following directory structure:

    weird/
        Jamfile
        b.c
        src/
            a.c
            c.c

The src/a.c file is like this:

    #include "src/a.h"

    int main(int argc, char *argv[])
    {
        return 0;
    }

The b.c file is like this:

    #include "src/b.h"

    int m

Re: Run Unit Tests for D library

Craig Allsop — 2012-09-30T00:56:23



These issues are because you need to set SOURCE_GRIST for each group of
sources, and given the outputs will also need to be seperate you'll need to
set LOCATE_TARGET to a new location. I suggest adding:

local SOURCE_GRIST = [ FGrist $(SOURCE_GRIST) unittest ] ;
local LOCATE_TARGET = [ FDirName $(LOCATE_TARGET) unittest ] ;

To your unit test rule. This will give the unit test .o files their own
flags and their own output directory, just like if you'd do if you had two
configurations like debug and release.

Craig.
_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Re: Run Unit Tests for D library

Chris Molozian — 2012-09-29T23:25:53

Hi Craig,

Thanks for your continued help with this, after a lot more 
experimentation and research into the way that D software libraries 
should be unit tested (idiomatically). I reworked much of my original 
build script into the following (pasted here so that it may be useful to 
someone in the future):

# INI configuration parser for the D programming language

ALL_LOCATE_TARGET = $(TOP) build ;
SubDir TOP ;

# UserObject object : source ;          handle .d suffix for Object
rule UserObject {
     switch $(>:S) {
      case .d : Dc $(<) : $(>) ;
      case * :
         Exit "Unknown suffix on " $(>) " - see UserObject rule in 
Jambase." ;
     }
}

# ObjectDcFlags source : flags ;        Add compiler flags for object
rule ObjectDcFlags {
     DCFLAGS on [ FGristFiles $(<:S=$(SUFOBJ)) ] += $(>) ;
}

# Dc object.o : source.d                .d -> .o
rule Dc {
     Depends $(<) : $(>) ;
     DCFLAGS on $(<) += $(DCFLAGS) $(SUBDIRDCFLAGS) ;
}

# UnitTest image : source ;             link unit tests exe from

Re: Run Unit Tests for D library

Craig Allsop — 2012-09-25T11:19:16


Did you ask jam to build '<release>app' ?

Also, you have a global and a target specific DFLAGS, you probably should
use different names for these as the 'on' will hide the global variable.
You can echo the value of DFLAGS to see what happens.



MkDir should never make anything with "/.", so check the LOCATE_TARGET
value.

Craig.
_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Re: Run Unit Tests for D library

Chris Molozian — 2012-09-19T15:27:33

Hi Craig,

Thank you for the continued help with setting up my build script, I feel 
that it's almost what I need. For the moment I've kept all the code in 
the Jamfile (but I plan to separate part of it into the Jamrules file 
later), based on your advice my build script looks like this:


ALL_LOCATE_TARGET = $(TOP) build ;
SubDir TOP ;

# override the Link action to correct for the dmd compiler -o flag
actions Link bind NEEDLIBS {
     $(LINK) $(LINKFLAGS) -of$(<) $(UNDEFS) $(>) $(NEEDLIBS) $(LINKLIBS)
}

rule ObjectDFlags {
     DFLAGS on [ FGristFiles $(<:S=$(SUFOBJ)) ] += $(>) ;
}

rule SetLocateTarget {
     LOCATE_TARGET = [ FDirName $(ALL_LOCATE_TARGET) $(SUBDIR) $(<) ] ;
}

rule BuildLib target : sources {
     local SOURCE_GRIST = $(CONFIG) ;
     SetLocateTarget $(CONFIG) ;
     Library <$(CONFIG)>$(target) : $(sources) ;
     ObjectDFlags $(sources) : $(DFLAGS) ;
}

DC = dmd ;
DFLAGS = -fPIC -w ;
LINK = $(DC) ;

DFLAGS on release = -release -O -inline ;
DFLAGS on debug   = -unittest ;
CONFIG on r

Re: Run Unit Tests for D library

Craig Allsop — 2012-09-19T10:47:20

Hi Chris,

On Tue, Sep 18, 2012 at 11:41 PM, Chris Molozian <chris< at >cmoz.me> wrote:


1. I'd set LOCATE_TARGET like so:

LOCATE_TARGET = [ FDirName $(ALL_LOCATE_TARGET) $(SUBDIR) release ] ;

Then you won't loose your all locate target, or better yet, make a
SetLocateTarget rule so you don't forget.

2. As I was saying before you can store configuration specific values by
doing this:

DFLAGS on release = -release ;
DFLAGS on debug = -unittest ;
CONFIG on release = release;
CONFIG on debug = debug ;

You could put these globally in jamrules for all libraries to use. I
created a rule to set such configuration variables and another rule to set
sub dir overrides. This allows you to make generic rules. e.g.

rule BuildLib target : sources
{
  local SOURCE_GRIST = $(CONFIG) ;
  local LOCATE_TARGET = $(CONFIG) ; # or use SetLocateTarget
  Library <$(CONFIG)>$(target) : $(sources) ;
  ObjectDFlags $(sources) : $(DFLAGS) ;
}

Stick that rule in jamrules, now your jamfile should be as simple as:

SubDir TOP ;
on debug

Re: Run Unit Tests for D library

Chris Molozian — 2012-09-18T13:41:51

Hey Craig,

Thanks for getting back to me so fast, I would have replied sooner but 
I've spent a lot of time trying to grok the Jambase file and all the 
builtin rules. At a conceptual level I'm writing a D library that I'd 
like to make use of D's unit testing features with, I'd like the build 
logic flow as follows:

 1. Compile all D sources with debugging flags and unittests.
 2. If successful, run the generated unittest code.
 3. If successful, compile the D sources with release flags.
 4. Success =)

I've put together the following Jamfile so far:

ALL_LOCATE_TARGET = build ;
SubDir TOP ;

DC = dmd ;
DFLAGS = -fPIC ;
LINK = $(DC) ;

# override the Link action to correct for the dmd compiler -o flag
actions Link bind NEEDLIBS {
     $(LINK) $(LINKFLAGS) -of$(<) $(UNDEFS) $(>) $(NEEDLIBS) $(LINKLIBS)
}

rule ObjectDFlags {
     DFLAGS on [ FGristFiles $(<:S=$(SUFOBJ)) ] += $(>) ;
}

DFILES = [ GLOB src : *.d ] ;

SOURCE_GRIST = debug ;
LOCATE_TARGET = debug ;

GenFile <release>app : <debug>app ;
Library

Re: Run Unit Tests for D library

Craig Allsop — 2012-09-08T03:41:43

Hi Chris,

On Sat, Sep 8, 2012 at 9:31 AM, Chris Molozian <chris< at >cmoz.me> wrote:

You can either run jam with a flag to set the configuration, e.g. "jam
-sCFG=debug sometarget" which you can use to switch different flags,
but I prefer using the 'on' syntax to empower the stock rules and
enable different flags for different configurations and build any/all
configurations in one step.

This may help:
http://maillist.perforce.com/pipermail/jamming/2008-December/002273.html
http://maillist.perforce.com/pipermail/jamming/2008-December/002285.html


Have a look at the built in GenFile action, its form is:

GenFile someoutput : executable inputs ;

If 'executable' is a target somewhere else, it will be built prior to
building 'output'. You will see in the actions that the first source
$(>[1]) is used as the 'program' to run. If you only want the above to
run for debug builds, then just don't make your release target depend
on 'someoutput'.

Craig.
_______________________________________________
jamming mailing list

Run Unit Tests for D library

Chris Molozian — 2012-09-07T23:31:02

Hey all,

I've added the extra rules from the FT version of Jam (ftjam) to my 
Jamfile that provide rules and actions to build D code with Perforce Jam.

The D programming language has built in support for Unit Testing 
<http://dlang.org/unittest.html> by passing the "-unittest" flag to the 
compiler. Unit testing code is then bundled with the generated 
executable and executed after static initialization but before the 
main() function is called.

I'm unsure how to do two things:

  * Create debug (default) and release build actions to allow me to pass
    the "-unittest" flag in a debug build but ignore unit test code in
    production releases.

  * Create an action that is run as part of debug builds that executes
    the generated binary to run it's unit tests.

All help is greatly appreciated.

Thanks,

Chris

_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Re: Does Jam need an error/warning stronger than"Usingindependent target X"?

Hubert Mackenberg — 2012-09-03T14:55:23

Hello Alan,

for me such a check is good design.

The only reason not to have such a check is that it may complain
about existing rules ;-)

Regards,
Hubert



From:
Alen Ladavac <alenl-ml< at >croteam.com>
To:
Jamming <jamming< at >perforce.com>
Date:
03.09.2012 11:28
Subject:
[jamming] Does Jam need an error/warning stronger than "Using independent 
target X"?
Sent by:
<jamming-bounces< at >maillist.perforce.com>



Hi all,

If I do something like this in Jam:

-----8<-------

rule Test {
  Depends all : $(1) ;
}

actions Test {
  copy $(2) $(1)
}

Depends all : source.txt ;

Test final.txt : intermediate.txt ;
Test intermediate.txt : source.txt ;

-----8<-------

When "source.txt" exists, while "intermediate.txt" and "final.txt" don't, 
this build will fail on the first run (because it will try to generate 
final.txt before generating intermediate.txt). It will however generate 
intermediate.txt  and will therefore pass on the second run. This problem 
happens due to an oversight in the dependency graph here. The "Test"

Does Jam need an error/warning stronger than "Usingindependent target X"?

Alen Ladavac — 2012-09-03T09:18:06

Hi all,

If I do something like this in Jam:

-----8<-------

rule Test {
  Depends all : $(1) ;
}

actions Test {
  copy $(2) $(1)
}

Depends all : source.txt ;

Test final.txt : intermediate.txt ;
Test intermediate.txt : source.txt ;

-----8<-------

When "source.txt" exists, while "intermediate.txt" and "final.txt" don't, this build will fail on the first run (because it will try to generate final.txt before generating intermediate.txt). It will however generate intermediate.txt  and will therefore pass on the second run. This problem happens due to an oversight in the dependency graph here. The "Test" rule should include a "Depends $(1) : $(2)" . We see this kind of scenario every once in a while, and it gets into production because a developer working on this is unlikely to try a clean build and will be unaware that the problem exists, especially in larger codebases, and when using parallel builds makes things like this pass or fail on random.

But... Jam doesn't report this as an error. The only warnin

Jam on AS400 - GLOB does not work.

Davidson, Giles — 2012-06-27T15:22:47

Hi,

We are planning to use Jam on the POSIX subsystem of i5OS on the AS400. The GLOB rule does not work - it looks to me as though it is ASCII specific. Has anyone ported Jam to the AS400 or the zOS USS and fixed GLOB for EBCDIC  - and if so could they share the fix?

Thanks
Giles
_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Re: Major Programs Using Jam?

Vladimir Prus — 2011-07-02T08:36:40

It should be noted that Boost.Jam is heavily modified to support Boost.Build,
and is not supported for 'standalone' use without Boost.Build. In fact,
in current SVN, the "Boost.Jam" brand is being retired, in particular
the documented executable name is 'b2' and not 'bjam', and it is referred
to as "Boost.Build engine". Obviously, I'd be happy if folks use Boost.Build,
but it should be noted that it is only very remotely similar to Jam at
this point.

Re: Major Programs Using Jam?

Chris Molozian — 2011-07-02T08:23:41

Dear Anuj,

The freetype <http://freetype.sourceforge.net/index2.html> project uses 
Jam <http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/Jamfile>.
Haiku OS <http://haiku-os.org/> use their own slightly customized 
version of Jam <https://www.haiku-os.org/guides/building/jam>.
The C++ Boost.Build system <http://www.boost.org/boost-build2/> is based 
on a modified version of Jam 
<http://en.wikipedia.org/wiki/Perforce_Jam#Boost.jam>.

I'd recommend trying the FTJam <http://www.freetype.org/jam/index.html> 
version of Jam, I'm using it in a D project of mine to build across all 
platforms (tested on Windows, Linux and Mac OS X). No more individual 
makefiles for each compiler and OS combination ;-) . The mailing list's 
very helpful too, if you get lost or stuck post again.

Hope this helps,

Chris


On 07/02/11 04:15, Anuj Goyal wrote:
_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Major Programs Using Jam?

Anuj Goyal — 2011-07-02T03:15:46

What major projects (open source or commercial) still use Jam?
_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Re: Simple C++ Project

Diane Holt — 2011-06-22T00:25:49

Okay, but a couple of things:

1. I prefer to keep the target with the source -- that way, if you modify
any of it, you can just 'jam' right from there, instead of having to figure
out where the target actually is and cd to there first.
2. That C++FILES is a global var, so if you use it anywhere else, it'll end
up set to whatever the last value is.

Diane

On Tue, Jun 21, 2011 at 2:04 PM, Chris Molozian <chris< at >cmoz.me> wrote:

_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

Re: Simple C++ Project

Chris Molozian — 2011-06-21T21:04:48

Thank you both. I like the only-one-Jamfile option. The library isn't 
going to be large, it's a nice concise solution. Job done. :-)

Chris


On 06/21/11 20:58, matthew conte wrote:
_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming