Re: Request for comments: CONS specification

On Wed, 2 Jun 2004 05:09:54 +0000 (UTC)
Steven Knight <[email protected]> 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


_______________________________________________
[email protected]
http://lists.gnu.org/mailman/listinfo/cons-discuss
Cons URL: http://www.dsmit.com/cons/