RE: Problem with dependancies

[Nadim Khemir]

Hi,

IMHO, I don't think the possibility to have cons take VS compiler by default
(if found) is a good solution. I have 3 compilers on my win32 computer. I
can easily switch from one to another with a bat file. 

Using cons::MSVC is better and clearer on the construct file.

For msvc users:
I understand why one should want to use cons::MSVC Instead for remembering
to run vcvars32.bat, but that is typical programmer laziness, write a
program to do settings instead of doing the settings once for all manually.

If you set the variables, vcvars32.bat sets, through "my
Computer/Properties/....." then the normal cons environment works fine.

Nadim.

> -----Original Message-----
> From: Rajesh Vaidheeswarran [mailto:address@hidden
> Sent: Thursday, April 04, 2002 5:26 PM
> To: Johan Holmberg
> Cc: address@hidden; address@hidden
> Subject: Re: Problem with dependancies
> 
> 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/
> >
> 
> _______________________________________________
> address@hidden
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/