Re: Cygwin, GNU make and VC++ ?

["Peter A. Castro" <doctor at fruitbat dot org>]

On Tue, 29 Oct 2002, Christophe Dupre wrote:

> Can you share this script with us ?

You know, one of these days I'm going to have to actually check my facts
before I go and open my mouth :)

I've reviewed my little scripts cl & link (wrote them a while ago and
just now actually *looked* at what they do :).  They are much more basic
than I remembered and have a few assumptions.  I've attached them for
your perusal. 

These assumptions are as follows:

1) The compiler and linker can handle "/" as a directory separator (this
is true for VC++ 5 but not widely known, (I think)), as well as handle
"-" as a switch character (also true for VC++ 5). 

2) Use real, non-cygwin specific, paths (is: no symlinks and no mount
points) in the include path specifiers (eg: "-IC:/users/pcastro/include"
instead of "-I/home/pcastro/include").  This isn't such a difficult thing
to do, depending on how your makefiles are designed, but if you are in a
mixed environment it can be a pain. 

3) The scripts are earlier in the PATH than the compiler is.

The attached scripts check for VC++ 5 env vars which are usually set thus:

export MSDEVDIR=C:/DevStudio/SharedIDE
export MSVCDIR=C:/DevStudio/VC
export VCOSDIR=WINNT

The real goal of the scripts was to set INCLUDE and LIB and PATH
correctly and just invoke the compiler.  We couldn't do this in our
makefiles because our build infrastructure had already claimed these as
macros (which were being exported by make :-( and thus caused the
compiler & linker to fail to find standard includes and linklibs.  Since
our build environment required a source home root to be defined and used
for all other file/path references (eg: SRCHOME=C:/users/pcastro) it
wasn't difficult to simply use it in our compile statements.
eg:
cl -c -Fofoo.obj -Ox -Oy- -Z7 -I. -I$(SRCHOME)/include foo.c
link /debug /debugtype:both /pdb:none /out:$(SRCHOME)/bin/foo.exe \
/MAP /LIBPATH:$(SRCHOME)/lib /NOD foo.obj kernel32.lib advapi32.lib \
user32.lib msvcrt.lib oldnames.lib winmm.lib

This has worked pretty well for us, but then we use a fairly ridged
development process.  Anyway, updating the script to actually parse the
command line and look for -I wouldn't be too difficult to do either.

Sorry if this isn't what you are looking for.

> On Tue, 29 Oct 2002, Peter A. Castro wrote:
> 
> > On Mon, 28 Oct 2002, Christophe Dupre wrote:
> >
> > > Hello everyone,
> > > I'm trying to recompile a homegrown program that was originaly
> > > developped for Unix under Windows. We were successful in compiling this
> > > program with the cygwin-supplied gcc using our current Makefile.
> > >
> > > Now we'd like to recompile with the 'native' compiler, cl.exe provided
> > > with Visual Studio, as some believe the native compile would produce
> > > faster binaries (it's a long-running analysis code - even 5% speedup
> > > would be significant). Also, the gcc binary can't seem to be able to
> > > allocate more than 1024MB of memory, even though the machine has 4GB
> > > physical (this is under Windows 2000). Even then, we had to modify a
> > > registry key to be able to use more than 256MB, which is not great for
> > > end-users.
> > >
> > > Anyway, we're making progress in being able to compile with CL.EXE, but
> > > we're having trouble with include files. We use the flag
> > > '-I/home/user/dg/include' to point to the include directory, but it
> > > can't find it. If we use '-I../include' it works, but for many reasons
> > > we need to be able to specify absolute paths for include files.
> > >
> > > Has anyone done that ? I was not able to find anything relevant in the
> > > archives.
> >
> > I had this same problem to contend with at work.  I'd solved it by
> > writing a wrapper script around cl that massaged the include list to
> > match Windows syntax and then invoke the real cl.  It was a but tricky.
> > I ended up putting the path with my wrapper earlier in $PATH and calling
> > cl.exe explicitly.  Had to do the same thing with link and lib commands
> > too.
> >
> > > Thanks.
> >
> > --
> > Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
> > 	"Cats are just autistic Dogs" -- Dr. Tony Attwood
> 
> --
> Christophe Dupre
> System Administrator, Scientific Computation Research Center
> Rensselaer Polytechnic Institute
> Troy, NY        USA
> Phone: (518) 276-2578  -  Fax: (518) 276-4886

-- 
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Attachment: cl
Description: cl

Attachment: link
Description: link

Attachment: dumpbin
Description: dumpbin

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/