Re: [Devel] Questions about Jam

[David Turner]

Hi Tom,

Tom Kacvinsky a écrit :
> 
> Hi all,
> 
> I have a coule of comments/questions about use of Jam.
> 
> I can think of a couple of people who lead other open source type projects who
> will be dismayed that FT is going to move torwards Jam for the build process.
> Will autoconf/libtool still be supported for UN*X like platforms?
>
I knew this question would arise :-)
 
> Possibly jumping the gun here, but ...
>
Note really, because "jam" is compatible with Autoconf and Libtool :-)
It _only_ replaces Make, and nothing else, and does an _excellent_ job
at that..
 
> Will Jam build shared objects?  I got Jam to successfuly build a standard
> archive library for static linking.  But no shared object was built.
>
Jam can build shared objects, use the following:

    export CC="libtool --mode=compile cc"
    export LIB="libtool --mode=link ar -ru"
    export LINK="libtool --mode=link cc"
    jam

and it will use "libtool" on Unix to build everything as usual.

The way Jam supports DLLs is still rather un-inintituive, but it's
making progress. I want to work with the main Jam team to enhance it
in order to add simple rules to build shared objects and DLL in
a simple way..

It would be trivial to change Jam to support libtool on Unix systems,
but I'd like something that is more consistent, i.e. that would allow
both the generation of shared objects on Unix and DLLs on Windows.
Unfortunately, the Windows DLL side of things is not standardized
yet in the current version of Jam (but several working proposals
have been made)

Jam also hasn't any official "jam.rpm" or "jam.deb" available on
Linux, and I think it'd be interesting if we could provide these
for other distros..

Jam has a few other benefits over our current build system:

  - jam is capable of creating executables easily

    (if you haven't looked at the Makefile for "ft2demos", they're
     _pretty_ complex and difficult to understand given the very
     distinct linking command line patterns used by the compilers
     we support.)

  - jam is capable of running executables, scripts, python programs,
    etc.. easily

    (think about automatic unit tests, API reference generation,
     etc..)

  - jam is capable of running an executable, and using its output
    to generate something else used in the build process

     (automatic file generation for "src/psnames/pstables.h", etc..)


 
> What about install targets?
>
Jam supports them too. Have you looked at the "Jamfile" that
comes with the "jam" module itself. It contains targets to
install, package, etc..
 
> Fianlly, some questions about Jam:
> 
> Which C compiler is it using?  The build output just lists Cc, with no
> indication of which compiler and/or flags are being used.
>
It depends on the platform. You should definitely have a look at
the file named "Jambase" in the "jam" module. It defines the
default jam behaviour (and can be overriden with the -f flag
by the way). The syntax is straightforward.

On Unix, it uses the value of "CC", or "cc" by default..
Jam configuration may change a lot between platforms. However,
"Jamfiles" stay the same..

Jam doesn't print the commands, except when an error occured. I find
it a lot cleaner and simple than the traditional "make" way. You can
still print the commands with a debugging flag though. see the Jam
documentation for details..

I really, really, think that Jam has a bright future and that more
projects should use it. I have only started using it for a month, 
but it's really a refreshing change from the current Make tools
I've known to date..

And it doesn't try to be a configuration tool :-)

Hope this helps,

Regards,

- David