headers
Matt Armstrong | 14 May 2004 19:45

Re: invoking external build processes

You MD5-sum the jam variables that affect the build (#defines and other
compiler flags).

Alan Baljeu <alanb <at> cornerstonemold.com> writes:
> I'm missing something here.  How do you get Jam to read the contents of 
> the file you want to MD5?
> 
> ----- Original Message ----- 
> From: "Matt Armstrong" <matt <at> lickey.com>
> To: <jamming <at> perforce.com>
> Sent: Friday, October 03, 2003 11:35 AM
> Subject: Re: [jamming] invoking external build processes
> 
> 
> > If the information to be updated is expressed completely within the
> > jamfiles, then a built in MD5 rule might get you going.
> > 
> > We have a header file that contains all the configuration #defines in
> > our project.  It is currently built "ALWAYS" by a perl script, but that
> > causes a full build.
> > 
> > So I added an MD5 builtin rule to Jam.  Jam computes the MD5 sum of all
> > the #defines and creates blddefs-<md5sum>.h.  Then we have rules to copy
> > that file to blddefs.h.
> > 
> > That way, it'll only regenerate blddefs.h when the list of configuration
> > values changes.
> > 
> > See //guest/matt_armstrong/jam/patched_version/... in the public
> > perforce demon.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dana Frost | 4 May 2004 02:23
Favicon

Using Jam along with Ant for Java

I just started working with this Make system and for the Java compile "Ant"
is used. There are some problems because the *.jar dependency is not set up
in a typical *.java -> *.class -> Project.jar way.

What I am wondering is if anyone has any experience using "Ant" to compile
Java but using "Jam" as the overall make system. Obviously there is a mix of
C and Java and Jam fits well with the "C" code but often Java *.jars are
place in libraries and are build too often.

I was also wondering if anyone has defined some rules for building Java
projects with Ant.

Dana
Permalink | Reply | 0 comments |
headers
Igor Bukanov | 5 May 2004 09:39

external program output -> variable

Hello!

Is it possible to initialize a variable from an output of external program?

freedesktop.org provides a utility called pkg-config, 
http://www.freedesktop.org/Software/pkgconfig that prints compilation 
and linking flags for various libraries and I would like to initialize 
CCFLAGS and LINKFLAGS from its output.

Currently I use a hack like:

CCFLAGS += "`pkg-config --cflags gtk+-2.0`" ;
LINKLIBS += "`pkg-config --libs gtk+-2.0`" ;

but this relies on shell magic and will execute pkg-config for each and 
every compilation and linking. Instead I would like to write something like:

CCFLAGS += [ RunCommand pkg-config --cflags gtk+-2.0 ] ;
LINKLIBS += [ RunCommand pkg-config --libs gtk+-2.0 ] ;

The question then is how to implement RunCommand ?

Regards, Igor
Permalink | Reply | 7 comments |
headers
Vladimir Prus | 5 May 2004 09:55
Picon
Favicon

Re: external program output -> variable

Igor Bukanov wrote:
> Hello!

Hi Igor,

> Instead I would like to write something
> like:
>
> CCFLAGS += [ RunCommand pkg-config --cflags gtk+-2.0 ] ;
> LINKLIBS += [ RunCommand pkg-config --libs gtk+-2.0 ] ;
>
> The question then is how to implement RunCommand ?

This question arises quite regularly, in particular, the same was requested 
several times on Boost.Jam mailing list.

The implementation is going to be straightforward, for example, on Unix you'd 
just fork a child and read from a pipe. However, making the implementation 
portable and robust would require some effort. Maybe, it makes sense to steal 
implementation from APR (Apache portable runtime), or from some other 
library.

If somebody, say you, could do that, it would be really great.

- Volodya
Permalink | Reply | 5 comments |
headers
Igor Bukanov | 5 May 2004 10:20

Re: external program output -> variable

Vladimir Prus wrote:
 >
 > This question arises quite regularly, in particular, the same was 
requested
 > several times on Boost.Jam mailing list.
 >
 > The implementation is going to be straightforward, for example, on 
Unix you'd
 > just fork a child and read from a pipe. However, making the 
implementation
 > portable and robust would require some effort. Maybe, it makes sense 
to steal
 > implementation from APR (Apache portable runtime), or from some other
 > library.

But Jam already knows know to execute actions and extending that code 
with piping should not be that difficult on unix/windows AFAIK. Of cause 
I have no idea how to do it on Mac classic or VMS but then Apache does 
not run there either (AFAIK again)....

Regards, Igor
Permalink | Reply | 4 comments |
headers
Andrew Marlow | 5 May 2004 10:46
Picon
Picon

bulding more than one exe with a Jamfile

Hello,

I am new to Jam and do not know how to get jam to
build multiple executables with a single Jamfile.
I have a directory full of test programs.
The arrangement is one '.t.cpp' file per test.
All tests are linked with the same set of libraries,
same compiler, same compiler options. So it seems
reasonable to me to have just one Jamfile that says
to build all the tests.
Can this be done please? How?

Regards,

Andrew Marlow
----
There is an emerald here the size of a plover's egg!
Permalink | Reply | 0 comments |
headers
Vladimir Prus | 5 May 2004 11:03
Picon
Favicon

Re: external program output -> variable

Igor Bukanov wrote:

> But Jam already knows know to execute actions and extending that code
> with piping should not be that difficult on unix/windows AFAIK. 

Sure, not that difficult as to be impossible, but difficult enough so that 
nobody implement it yet.

The question that bothers me, for example, is: do you catch stdout, or stdout 
and stderr? And if you catch both, you need to make sure the forked process 
is not blocked writing to stderr, while jam is blocked reading from stdout.

- Volodya
Permalink | Reply | 3 comments |
headers
Ingo Weinhold | 5 May 2004 11:48
Picon

Re: external program output -> variable

On Wed, 5 May 2004, Vladimir Prus wrote:

> Igor Bukanov wrote:
>
> > But Jam already knows know to execute actions and extending that code
> > with piping should not be that difficult on unix/windows AFAIK.
>
> Sure, not that difficult as to be impossible, but difficult enough so that
> nobody implement it yet.

Well, that's only partially correct. It is quite simple to implement it on
platforms that provide popen(). Unless I deleted it accidentially I should
even have a patch for it lying somewhere on my harddisk.

But there are philosophical reasons, why such a feature won't be accepted
by the maintainer.

> The question that bothers me, for example, is: do you catch stdout, or stdout
> and stderr? And if you catch both, you need to make sure the forked process
> is not blocked writing to stderr, while jam is blocked reading from stdout.

In doubt the user can just redirect stderr.

CU, Ingo
Permalink | Reply | 2 comments |
headers
Turner David | 5 May 2004 11:54

RE: bulding more than one exe with a Jamfile

Hello,

> Hello,
> 
> I am new to Jam and do not know how to get jam to
> build multiple executables with a single Jamfile.
> I have a directory full of test programs.
> The arrangement is one '.t.cpp' file per test.
> All tests are linked with the same set of libraries,
> same compiler, same compiler options. So it seems
> reasonable to me to have just one Jamfile that says
> to build all the tests.
> Can this be done please? How?
> 

Just create a small loop and call the relevant rules
in each iteration. For example:

PROGRAMS = program1 program2 program3 ;

for t in $(PROGRAMS)
{
  Main           $(t) : $(t).c ;
  LinkLibraries  $(t) : $(MYLIBS) ;
}

Hope this helps,

- David Turner
(Continue reading)

Permalink | Reply | 752 comments |
headers
Vladimir Prus | 5 May 2004 11:57
Picon
Favicon

Re: external program output -> variable

Ingo Weinhold wrote:
> On Wed, 5 May 2004, Vladimir Prus wrote:
> > Igor Bukanov wrote:
> > > But Jam already knows know to execute actions and extending that code
> > > with piping should not be that difficult on unix/windows AFAIK.
> >
> > Sure, not that difficult as to be impossible, but difficult enough so
> > that nobody implement it yet.
>
> Well, that's only partially correct. It is quite simple to implement it on
> platforms that provide popen(). Unless I deleted it accidentially I should
> even have a patch for it lying somewhere on my harddisk.

Right, 'popen' is handy. But last time I tried pipes on Windows, that was much 
more complicated that popen/fork which we have on Unix

> But there are philosophical reasons, why such a feature won't be accepted
> by the maintainer.

Well, 
1. If there's a patch, interested persons can obtain/apply it separately.
2. At least we can get this patch in Boost.Jam...

> > The question that bothers me, for example, is: do you catch stdout, or
> > stdout and stderr? And if you catch both, you need to make sure the
> > forked process is not blocked writing to stderr, while jam is blocked
> > reading from stdout.
>
> In doubt the user can just redirect stderr.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane