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:
_______________________________________________
jamming mailing list  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

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 and execute:

    jam foo.o

What shall I write in the Jamfile? Note that src/foo.h does not
exist and hence it has to be generated in some way. I tried with
the following Jamfile.

    CreateHeader src/c.h ;
    rule CreateHeader
    {
        Clean clean : $(1) ;
    }
    actions CreateHeader
    {
        echo "int x = 10;" > $(1)
    }
    Object foo.o : src/foo.c ;
    CreateHeader src/foo.h ;

Note that this Jamfile works if I generate src/foo.h in advance with
a separate Jam invocation:

    jam src/foo.h ; jam foo.o

Dario D'Amico

---------- Original Header -----------

To          : dario.damico< at >damix.it
Cc          : jamming< at >maillist.perforce.com
Date      : Thu, 25 Oct 2012 08:03:44 +0200
Subject : Re: [jamming] Object rule and directories



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

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 main(int argc, char *argv[])
    {
        return 0;
    }

The src/c.c file is like this:

    #include "c.h"

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

The Jamfile is:

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

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

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

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

The following command correctly creates b.o and src/b.h:

    jam b.o

The following command creates src/a.h, but then GCC fails to create a.o; the reason
is quite obviously that the #include in a.c mentions src/a.h while in fact should simply
refer to a.h:

    jam a.o

The following command fails completely, and does not even create c.h; the reason is
probably that when Jam analyzes c.c it generates a dependency on c.h instead of src/c.h,
and in the Jamfile there are no rules for generating c.h:

    jam c.o

This command compiles properly if I explicitly ask to generate src/c.h before asking for c.o:

    jam src/c.h
    jam c.o

In my opinion the jam src/c.h should not be necessary. What's wrong here? Check the Jam
manual for more information, particularly under the section Header File Scanning.

Thank you for your help.

Dario D'Amico





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

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 
compiled sources
rule UnitTest {
     local SRC = $(>) test/emptymain.d ;
     local DCFLAGS = $(DCFLAGS) -unittest ;

     MainFromObjects unittests : $(SRC:S=$(SUFOBJ)) ;
     LinkLibraries unittests : pegged ;
     Objects $(SRC) ;
     GenFile $(<) : unittests ;
}

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

DC = dmd ;
DCFLAGS = -O -release -w -property -Isrc -IPegged ;
LINK = $(DC) ;

SRC = [ GLOB src : *.d ] ;

UnitTest results : $(SRC) ;
Depends inid$(SUFLIB) : results ;
Library inid : $(SRC) ;
LinkLibraries inid : pegged ;
ObjectDcFlags $(SRC) : -inline ;

Library pegged : Pegged/pegged/peg.d
         Pegged/pegged/grammar.d
         Pegged/pegged/parser.d
         Pegged/pegged/introspection.d ;



This does work but has the following quirky behavior:

  * DCFLAGS appear to be supplied twice to the compiler (shown using
    `jam -dx`)
  * The `-inline` flag is passed to the UnitTest compilation when it
    should only be applied to regular builds.
  * There is no distinction between "unit test" sources and release
    library sources.

The biggest issue with the above build script is that sources compiled 
for unit tests are then overwritten for sources compiled for the library 
release. There's no separation of contexts. If you can spare any time 
and could give me a few ideas on where to make changes on the above 
points you can find the repository here:

https://github.com/novabyte/ini.d

Cheers,

Chris


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

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 release = release ;
CONFIG on debug   = debug ;

DFILES = [ GLOB src : *.d ] ;

GenFile output : <debug>app ;
Depends <release>app : output ;

on debug BuildLib app : $(DFILES) ;
on release BuildLib app : $(DFILES) ;


I'm pretty sure that my `Depends <release>app : output ;` isn't working 
at all, so the build of a release version of the library is not 
triggered after the successful execution of a debug build. I've also 
noticed that none of the DFLAGS are being applied during compilation.

With these changes it's strange but the build will always fail the first 
time in a completely clean workspace with these errors:

$> jam -dax
...found 19 target(s)...
...updating 8 target(s)...
MkDir1 build
mkdir build
MkDir1 build/.
mkdir build/.
mkdir: build/.: File exists
...failed MkDir1 build/. ...


Cheers,

Chris


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

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 BuildLib app : $(DFILES) ;
on release BuildLib app : $(DFILES) ;

By using "on x" syntax you bring all variables set on 'x' into scope in one
hit, thus your BuildLib rule then receives the relevant value. This
technique can also be used to extend the standard rules in many cases.

3. ALL_LOCATE_TARGET should be set from the TOP so that if you build from a
sub-directory the all locate target directory will stay put.

ALL_LOCATE_TARGET = $(TOP) build ;



4. The GenFile rule first argument is the output of the program named in
the second argument (with optional inputs) so should be more like:

GenFile someoutput : <debug>app ;

And your release intermediate targets, e.g. .o files and <release>app
should depend on 'someoutput'. Then if you ask jam to build <release>app it
will first build and run <debug>app and with no build error continue on to
build the release version. If you want to build the release without doing
this as well you'll need to create a mirror on the release targets, e.g.
'quickrelease' as your grist and you command jam to build <quickrelease>app
instead.

Hope that helps.

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-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 <debug>app : $(DFILES) ;
ObjectDFlags $(DFILES) : -unittest ;

SOURCE_GRIST = release ;
LOCATE_TARGET = release ;

Library <release>app : $(DFILES) ;
ObjectDFlags $(DFILES) : -release ;

I've used `ALL_LOCATE_TARGET = build ; SubDir TOP ;` to try and force 
all build output to a "build" folder but that seems to be ignored after 
I defined the SOURCE_GRIST and LOCATE_TARGET variables.

At the moment, the two builds happen but independently of each other. 
Ideally I'd like to the release build happen only if the execution of 
the binary created by the debug build is successful.

Any ideas on how to do this?

Many thanks for your help so far,

Chris


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

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  -  jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

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" 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 warning close to this
is the "warning: using independent target X". But it only checks whether
both inputs and outputs of an action are dependencies of _something_. It
doesn't check whether outputs of an action depend on its inputs. (This why
I added "Depends all : source.txt" above, as having this source mentioned
anywhere else will make the warning go away for all other places.)

What I would like to ask the collective wisdom of this group is this: Is
there any reason why there is no error checking for whether an action
takes inputs that are not dependencies of the output?

It seems to me like the lack of this error check is an oversight in jam
implementation, rather than intentional design choice. But I cannot be
sure.

Before I rush implementing the check.... does anyone see a reason why such
an action should be valid?

Thanks,
Alen

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

#
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."
#
_______________________________________________
jamming mailing list - jamming< at >maillist.perforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

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 warning close to this is the "warning: using independent target X". But it only checks whether both inputs and outputs of an action are dependencies of _something_. It doesn't check whether outputs of an action depend on its inputs. (This why I added "Depends all : source.txt" above, as having this source mentioned anywhere else will make the warning go away for all other places.)

What I would like to ask the collective wisdom of this group is this: Is there any reason why there is no error checking for whether an action takes inputs that are not dependencies of the output?

It seems to me like the lack of this error check is an oversight in jam implementation, rather than intentional design choice. But I cannot be sure.

Before I rush implementing the check.... does anyone see a reason why such an action should be valid?

Thanks,
Alen

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

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