Re: Request for comments: CONS specification

[F. Schoenahl]

On Wed, 2 Jun 2004 05:09:54 +0000 (UTC)
Steven Knight <address@hidden> wrote:

Hello Steven,

(...)
> > "scons" requires reading local information and file changes and is
> > therefore long to trigger, "make" reacts very quick a contrario. AAP
> > is in the middle. That's a good point, when developping small-middle
> > scale project, It is always good to have a build system that doesn't
> > take too much time.
> 
> The next release of SCons looks like it will have some changes that
> will reduce the amount of time it takes to get started, at least for
> many configurations.

Very good point! I found a bit annoying the idle time when launching scons!

> > "SCons" has a make-like way to compile files, "aap" uses additional
> > directories aap-build-directories, where objects are stored. This
> > is a good idea because it avoids complex tunings to store objects at
> > specific places.
> 
> Can you elaborate on what you mean by "make-like way to compile files?"

It means that it compiles files in place, and the objects are stored at 
specified location. It is like that by default in SCons (afair) and Make. AAP - 
by default - builds everything to a specific directory.
Here, I only watch the "default" behaviour, as imho the build system should 
require a deep knowledge of its internals to be functional and running... 

> SCons does support a BuildDir() feature and build_dir argument to
> the SConscript() call that allow for placing target files in separate
> directories.  Is that what you meant?  (I want to make sure I'm not
> overlooking some functionality that we still need to add.)

Yes, target beeing "final" objects  like libraries or "intermediary" like 
c-objects. I think when I use scons, by default, I can "alias" some directories 
to build somewhere else - I was not happy with that, find it somehow "unclear" 
- and I think it copies all required data (not only targets) into the 
directory... 

What I wanted to do was to create the installation tree in-place. I think this 
is what a good build system allows, namely a project that looks like :

$ ls
  src*  include* lib* bin* README 

should be build by generating the lib - alone - into ./lib, so that the 
installation is extremely simple : cp (ginstall) -r include lib /usr

I remember that when "aliasing", not only the lib was copied to lib*, but all 
*.h files or something like that...

Maybe the latest versions of Scons make that more easy (I am not up2date with 
scons) - however if a good install feature is present, this is no more 
necessary.

> > "aap" has a very promising "configure" feature, which is very
> > experimental but imho, it is a very good idea to have configuration
> > skills for a build system, same language for the whole stuff +1
> 
> A-A-P and SCons collaborated on the underlying code for the autoconf-like
> functionality.  SCons supports this sort of configuration through its
> "SConf" subsystem, but unfortunately it's only documented in the man page,
> not in the User's Guide yet.

Ok, that's why I missed it - sorry for the credits, I did nt know about the 
common job.

SHould be -imho again- identified separately e.g. sconf and scons for easy 
understanding and use.

(..)
> > Imho, skip back compatibility with the current cons, this will make
> > things far easier.
> 
> Far easier to implement, but more work for people wanting to migrate to
> the new Cons, yes?  That may be the right choice, but the group working
> on this should make a conscious decision about what the priorities of the
> project will be: implementing quickly, or making it as easy as possible
> for previous Cons users to migrate.  Both have their pros and cons,
> but it will save headaches if everyone working on the project has the
> same clear understanding of the priorities from the beginning.

COns was not widespread and remains quite confidential against the traditional 
configure-make-make install .
I mean, maybe use this at cons's advantage to optimize now the language with 
the new objectives, and using the experience - before it becomes the ISO-answer 
to any linux beginner who does nt know how to build from the sources ("Just do 
(s)cons!" (c))  

I won't be so active, so it's up to the new "hands" to chose that... 

[... installation]

Bye,
fred