automake-patches
[Top][All Lists]
Advanced

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

Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS.


From: Ralf Wildenhues
Subject: Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS.
Date: Fri, 30 Jan 2009 00:14:36 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

* Peter Rosin wrote on Thu, Jan 29, 2009 at 04:39:16PM CET:
> Den 2009-01-28 13:41, skrev Ralf Wildenhues:
>>
>> You can install Autoconf below a different --prefix.
>
> Yes, but MSYS is MSYS is MSYS is a bitch. I fail to get automake
> to build even with autoconf-2.63 (in a new prefix, first in $PATH).
>
> I get this when I type "make" (after ./configure CC="bla bla bla")

>  cd .. && perllibdir="/home/peda/automake/git/automake/lib:./lib" 
> "/home/peda/automake/git/automake/automake" --libdir=lib --gnu
> /bin/sh: /home/peda/automake/git/automake/automake: No such file or directory
> make: *** [Makefile.in] Error 1

When building git Automake, start with ./bootstrap.  That way, you avoid
time stamp issues (which are likely to appear due to checked-out
generated files).  Sorry for the inconvenience.

>> Which gets me to the next question: if you haven't run the Automake
>> test suite, how have you tested this patch?  Does it rightly set
>> depmode to msvisualcpp on Cygwin, and to msvcmsys when using MSYS?
>> Does it produce correct dependencies?  In the end, I think it'd really
>> be the easiest if you showed testsuite results, including verbose output
>> for failures.  You need not take up work to fix all the failures you'll
>> probably encounter.  (At least not yet  ;->  )
>
> Since the patch is now limited to the depcomp program, I simple copied
> that file into libtool and played with configure.
> If I configure libtool like this, on MSYS
>
> ../configure --enable-dependency-tracking CC=".../path/to/compile cl" 
> CFLAGS="-MD -Zi"
>
> I get this output:
[...]
> checking dependency style of .../path/to/compile cl... msvcmsys
> checking whether .../path/to/compile cl and cc understand -c and -o 
> together... yes

> On Cygwin, with the same configure options:
[...]
> checking dependency style of .../path/to/compile cl... msvisualcpp
> checking whether .../path/to/compile cl and cc understand -c and -o 
> together... yes
> *snip*
>
> But I didn't test enough of course. Blast, it worked with depmode=cpp
> so I just assumed depmode=msvisualcpp was good enough too. Not so.

;-/

> depmode=msvisualcpp, when used with libtool clobbers the output file
> in the second invocation (with -E). So, I need to copy-paste some code
> from the depmode=cpp to filter out libtool (and -o $object) from
> that second invocation.

Yeah; I'm assuming that msvisualcpp depmode was written with an MSVC
version much older than the one you're testing with.

>> Can probably be done in principle, but would be hacky.  Not sure if that
>> is the /first/ bug I'd be trying to fix.
>>
>> It may mean that you have to
>>   export CC=".../path/to/compile cl"
>> for some of the testsuite tests though.  Bummer.
>
> Bummer. Exactly, being forced to feed various options to configure
> should be avoided. I't bad enough as it is...

Doesn't mean we shouldn't fix it.  But please, let's work on one thing
at a time.

>>>  +cygpath_u="cygpath -u"
>>> +if test "$depmode" = msvcmsys; then
>>> +   # This is just like msvisualcpp but w/o cygpath translation.
>>> +   cygpath_u=echo
>>
>> Why not something involving 'CMD //C'?
>
> Because MSVC spits out Win32 paths, no need to involve MSYS with those.

Ah, thanks.

>>> +  sed -n '/^#line [0-9][0-9]* "\([^"]*\)"/ s::echo "`$cygpath_u 
>>> \\"\1\\"`":p' | sort | uniq > "$tmpdepfile"
>>
>> sort -u?
>
> One fork less for each dep, thank you very much.

BTW, probably not: likely, sort just forks off uniq by itself.

> But if it's forks
> we're chasing, the echo in the echoed `subshell` isn't really
> defendable when some form of simple echo would do...

Do you have a better way with less forks?

> Ok, third iteration, taking care of all of the above except the
> echo `echo file` thing.
>
> But comparing the resulting depmode=msvisualcpp with depmode=cpp,
> maybe msvcmsys fit better as a tweeked cpp?
> That would get rid of a whole bunch of forks for each dep.
> (msvisualcpp is noticeably slower than cpp)

Well, sure, faster is better, but only if functionality is equivalent.

I have an old MSVC installation here to test, but that will take a
couple of days ... until then, any test results help.

Thanks,
Ralf

> 2009-01-29  Peter Rosin  <address@hidden>
>
>       Add depmode=msvcmsys for Microsoft Visual C++ on MSYS.
>       * lib/depcomp: Add depmode=msvcmsys as a derivative of
>       depmode=msvisualcpp. msvcmsys uses echo instead of "cygpath -u"
>       to prevent any path translation.
>       Also transform any backslashes into forward slashes to make the
>       grep in depend.m4 match.
>       Fork fewer processes for depmode=msvisualcpp.
>       Filter out libtool in the preprocessor invocation (as is done
>       in depmode=cpp) for depmode=msvisualcpp.




reply via email to

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