Re: [Devel] Relevance of FTjam wrt new Jam 2.4 ?

[Antoine Leca]

Salut David,

David Turner écrivit (wrote) :
> 
> Mark Leisher wrote:
> > What has been putting me off of learning Jam is the apparent lack of 
> > interest
> > by most of the free software development community.  There must be some
> > reason why it isn't being used, so I guess it is time to find out why.
> >
> I can think of several reasons for the current state of affairs:
> 
>    A - "most" free software developers work under Unix and don't
>        care if their code runs on different platforms (or when they
>        do, it's always a second-thought that they rarely fully commit
>        to).

Hmmm, I can even restrict the specter to Linux, + perhaps Sun/Solaris and
a bunch of related usual suspects. As a matter of fact, I repeatedly have
problem to have a number of projects, without anything graphics-oriented
or related to shared libraries, so which should be obvious to have working,
to really get working on Minix 386, which is really quite near from Linux
(but mush mush less used). I hear that the BSD guys are in similar position
more than often.

So, and also because I did have experience with writing portable specs,
I do believe that the portability problem is very often overexposed at the
conception time, and simultaneously undercovered when it comes to
maintenance.


>    B - The Jam documentation is really, really poor. One needs to
>        study the Jambase file in details to really understand well
>        how everything works.

This is essential. And I should record here that if make becomes a
successful
tool, this is certainly because it came with a decisive article that
describes
the wroking, along with the proven challenge that it was able to cut the
times
while designing Unix (the original). Jam is yet to have its killing
project,
and then, it will certainly need a much better documentation.

This is the same for GNU, BTW: one very good thing with GNU tools is that
very often they come with abundant documentation. Of course you can
disagree
with what is said inside this docs (I think about the Coding Standards, for
example), but the fact that it is overexplained, and in a easy to find way,
certainly do help people to get the hands at the tools.


>    C - "Make/Autoconf/Libtool/Automake" are available by default on most
>        Unix installations, while you need to install Jam manually.

This is not a very big problem. Look at Python: while it was clearly (in
functionnalities) a copy of Perl, when it became clear that the tool was
superior in some tasks (maintenaing, for example), and thus adopted by
many people, it became part of every Linux distributions.
I believe availability is a second-time problem. And there will have no
reason to keep undistributed, _when_ the product itself will have proven
essential in some projects.


>    D - Many advanced developers are used to pervert Autoconf+Make to
>        have them perform really sad tricks during a build process.
> 
>        These won't change their habits until they know that they can
>        do the same things with Jam "easily". This won't happen until
>        the Jam documentation becomes much more serious...

Even then, it will cost them a lot to migrate toward Jam.
I know that the syntax is not that different, so one could easily adapt
herself to Jam, but having to use at the same time two different tool
for the same job is always a problem (and I think part of Mark's question
comes from that point of view). So I think Jam should have a clear path
that allow one developper to migrate a (even big) project from autoconf+
make to Jam without too much trouble. Normally, the trouble should be
the things that are questionable in autoconf/make, so:
  a) they should be documented, at least in the mind of the developper,
    becasue if they are not the project simply unable to evolve...
  b) anyway, it would be a good thing that these questionable tricks
    will go away!
 

> I think that, as long as B and C isn't solved reasonably well, we're
> not going to see any change in habits in the free software world.

I believe B is critic, and C will follow with time if Jam is successful.


Antoine