libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Support for VC++ toolchain (was Re: Absolute paths generated by libtool.


From: Benoit Sigoure
Subject: Support for VC++ toolchain (was Re: Absolute paths generated by libtool.)
Date: Tue, 28 Nov 2006 12:54:09 +0100
User-agent: Internet Messaging Program (IMP) H3 (4.0.2)

Quoting Benoit Sigoure <address@hidden>:
[SNIP, see http://lists.gnu.org/archive/html/libtool/2006-11/msg00018.html]


Hello folks,
I think I finally succeeded: I can now build any UNIX program as long as its
code is portable on Windows with both mingw-gcc toolchain and MS VC++.

I thought this might interest you and I also have some (hopefully easy) feature
requests for libtool.

Let's summarize the whole problem: I have several projects being developped
under UNIX (more precisely Linux 2.6 and MacOSX). Many of them use Qt (which is
known for its portability) some don't and just depend on the libc and C++ STL.
Some of them have a build system provided by the Autotools, some others use
that provided by Qmake.
The problem is: given the fact that the code and its dependencies are portable
on Windows, how to automate the build of all these projects without having to
tweak the build system of each project so that it works on Windows.

Here is the solution I tailored: The build environment is provided by Cygwin.
This enables me to have an environment very POSIXish and UNIXish and I can use
the numerous packages provided by Cygwin.
I want to support two toolchains: mingw-gcc and MS VC++. Both don't understand
cygwin paths such as /home/build/foo/... Moreover, some build systems might
assume that they run in cmd.exe and use paths such as C:\Qt\4.2.1\bin\... and
the shell will remove the backslashes because they're not escaping anything. I
hooked the whole toolchain of mingw using symlinks in ~/bin (which appears
first in my PATH). They point to a shell script that does basically this:
if we're running make:
  exec make SHELL=my_shell.pl "$@"
if we're runnning a GNU compiler:
  exec my_shell.pl ccache "$@"
otherwise:
  exec my_shell.pl "$@"

my_shell.pl does this:
1/ Rewrite the command using UNIX binaries. For instance, calls to "del" are
rewritten using "rm", xcopy using "cp -rfp" etc.
2/ All the backslashes that aren't escaping a shell-special character are
changed in forward slashes.
3/ All absolute paths that start from "/" are rewritten so that they start from
C: or whatever.

The resulting command will have absolute paths of the form C:/Qt/4.2.1/bin/...
for instance, which everybody (Windows/mingw/cygwin) understands.

The VC++ toolchain is also hooked in a similar way. The shell scripts does set
all the environment variables that VC++ needs (most of them are provided in
vsvars32.bat).

Compiling for mingw is easy, a simple ./configure && make does the job.

I was rather surprised to discover that ./configure CC="cl.exe" CXX="cl.exe"
LD="link.exe" does the trick for VC++. I don't know if there's a special
support for this in libtool but it works although the build system uses the
host triplet i686-pc-cygwin (!).

The single problem that ocurred to me so far is that sometimes, libtool gives
weird names to object files, eg:
$(CC) -o foo-foo.obj -c foo.c

And cl.exe doesn't understand -o and generates "foo.obj" instead. Then linking
fails because it can't find foo-foo.obj. This is a very small problem I could
easily fix myself.

Now the question is: would consider support for VC++ in libtool? This would
imply doing something similar to what wgcc does, that is: rewritting all the
arguments (-I's, -D's etc) for VC++. I can (try to) contribute. Any suggestion?
Is there a libtool-HOWTO-hack guide?

Cheers,

--
SIGOURE Benoit aka Tsuna
  _____
 /EPITA\ Promo 2008, LRDE





reply via email to

[Prev in Thread] Current Thread [Next in Thread]