[Top][All Lists]
[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.
- Make depmode=cpp work with Microsoft Visual C++ on MSYS., Peter Rosin, 2009/01/26
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS., Ralf Wildenhues, 2009/01/28
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS., Peter Rosin, 2009/01/28
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS., Ralf Wildenhues, 2009/01/28
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS., Peter Rosin, 2009/01/29
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS.,
Ralf Wildenhues <=
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS., Peter Rosin, 2009/01/29
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS., Ralf Wildenhues, 2009/01/30
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS., Peter Rosin, 2009/01/30
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS., Peter Rosin, 2009/01/30
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS., Ralf Wildenhues, 2009/01/31
- Re: Make depmode=cpp work with Microsoft Visual C++ on MSYS., Peter Rosin, 2009/01/31