Re: Problem with dependancies

[Rajesh Vaidheeswarran]

I am not averse to getting Cons::Plus functionality into Cons (or the
cons distribution, initially).

There are a few issues that I have with Cons::Plus, nothing insurmountable.

I have cut-and-paste the highlights of Cons::Plus from the cons-plus.pdf
file (and for some reason. I had to manually insert some characters that
acrobat refused to treat as characters - happens mostly with TeX fonts).
I would like to have some of this addressed.

> Cons::Plus provides a number of features not found in plain Cons today:
> 
>     "On Win32,the location of your Visual C++installation is automatically
>     found,and the default ENV value in the Cons environment gets suitable
>     values for the variables PATH,LIB and INCLUDE.If you don't have
>     Visual C++installed,Cons::Plus falls back on the normal Cons defaults.

I like the general idea, but this should be confiburable via a flag, and
not the default. i.e., irrespective of whether there is a VC++ compiler
or not, cons scripts should behave the same way unless told explicitly
otherwise. The VC++ module (Cons::Vstudio) should handle this (and maybe
it already does - I haven't looked at the code). That way, tomorrow someone
can write a borland module or whatever and have it do what requires to
be done to use the borland compiler, etc...

This would eliminate the need for hardcoding the vc++ stuff in the win32
defaults.

>     "a new method clone_merge_env works like clone but  merges the
>     content of  ENV  in the argument on o he previous one (instead of
>     replacing it).

I like the idea, but I would rather have it merge a given set of variables,
and not just ENV (that would lead to more new methods being created for
other variables someone else might want to merge).

something more like...

$e = cons->new(...);
$x = $e->clone_merge(MERGE => { all merge variables }, # to be merged
                     var1 => "foo", # to be replaced
                     var2 => "bar", # to be replaced
                    );

Maybe something like that (hopefully, not exactly that) would solve it
more generally. This should definitely be basic cons functionality.

>     "Object files,libraries and executables can be placed in a separate
>     directory tree by specifying the variable BUILD_TOP .This works
>     almost like the  Link  command in plain Cons (but without creating
>     copies of the source files (not even hardlinked copies)).
>     
>     "Object files can be placed in a specified directory by using the
>     method ObjectsInDir (instead of Objects ).
>     
>     "Object files,libraries and executables can be placed in separate
>     directories by specifying the variables OBJDIR ,LIBDIR and BINDIR
>    in the Cons environment.

Maybe I'm mistaken, but I see three (maybe 2) ways of doing the same thing.


Other than these, I'm fine with merging them.

rv

In a previous message, Johan Holmberg writes:

> 
> On Tue, 2 Apr 2002 address@hidden wrote:
> >
> > Out of curiousity, why is Cons::Plus not merged into the main cons source?
> >
> 
> A similar question was asked in Nov last year. See my answer then:
> 
>     http://mail.gnu.org/pipermail/cons-discuss/2001-November/001639.html
> 
> 
> At least part of the Cons::Plus functionality could very well be
> added to main Cons.
> 
> For example: something like "ObjectsInDir" is obviously needed in
> Cons, since both you and I (and others) seem to have a need for
> something like that. With the current version of Cons it is
> *impossible* (via the "official" interfaces) to get the following
> two things at the same time:
> 
>    - compile a C/C++ file and place the output in a certain directory
>    - get the automatic header-file dependency checking
> 
> I think this is strange for a tool that is much more "programmable"
> than old make. A "loophole" in the Cons API's.
> 
> Other things in Cons::Plus may be more "controversial", and maybe
> only reflect the way *I* like to use Cons. I don't know ....
> 
> >
> >  Are there reliability issues I should be concerned about?
> >
> 
> Yes ;-)
> 
> I don't have a suite of test-cases for Cons::Plus. If some of the
> Cons::Plus functionality was added to main Cons, one would have to
> write some testcases to go along with the new functionality.
> I haven't felt the need to do that for Cons::Plus itself yet.
> 
> 
> I have no idea what the maintainers of Cons think about the
> functionality in Cons::Plus. If they were interested in adding some
> of the functionality to main Cons, I would of course do my best to
> help.
> 
> /Johan Holmberg
> 
> 
> 
> _______________________________________________
> address@hidden
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/
>