Re: Automatic dependency checking problems

On Fri, 07 May 2004 13:22:24 +0200, Bram Moolenaar
<[email protected]> wrote:

[...]

>> >I think the problem simply is that the msvc tool doesn't set $CC or
>> >$CXX.  It only sets $MSVC.
>> >
>> >So, should a tool like msvc set $CC and $CXX, so that all places where
>> >they are used will use the selected tools?  I suppose so.
>> 
>> I would say yes. I see the other tools do the same thing, and I'm not
>> sure why. Perhaps there is a reason for it, but I don't see an
>> explanation.
>> 
>> The tools also use undocumented variables like LINKFLAGS to set flags.
>> It seems to me that there should be standard variables for flags to the
>> standard tools.

>"it depends".  If we have a standard format for $LINKFLAGS then all
>tools can use it.  But if you have a project where some files are
>compiled with MSVC and some files with MingW, you might have link flags
>that differ.  Switching between the two tools should not result in the
>variables becoming invalid.

Hmm.. I see what you're saying, but what I'm seeing in the tools files
doesn't seem to match it. Currently, MSVC/BCC both use LINKFLAGS, while
MingW/GCC use the standard variable LDFLAGS.

Different compilers use the standard variable, so they obviously
conflict. And if the reason to use LINKFLAGS is to allow several
compilers to be used in a recipe, why use the non-standard variable
LINKFLAGS for several compilers? Instead of e.g. MSVCLINKFLAGS and
BCCLINKFLAGS.

>The $CC and $CXX are generic: the C and C++ compiler.  Thus when
>selecting a tool I think these variables should be set.  But variables
>specific for one tool should have a name that's only used by that tool.
>Does this make sense?

That does make sense, but then I wonder why variables like LDFLAGS even
exist. I think it's a little confusing the way it is. It's hard to know
which flags are used where, unless you go digging through the AAP code.

Also, if the linker requires separate flags, why not also the compilers?
Why does the MSVC compiler use the standard CPPFLAGS, but not the
standard LDFLAGS? Different compilers use different compiler flags, so
you couldn't use MingW along with MSVC even if they have different
linker flags.

And to continue in the same vein: Why use MSVC and MSLINK instead of
CC/CXX and LD? You indicated now that CC and CXX should be set to the MS
compiler, so is there a need to use MSVC anymore? Was there ever really
a need for that?

[...]

>> cl : Command line warning D4002 : ignoring unknown option
>> '/cygdrive/c/DOCUME~1/THOREK~1/LOCALS~1/Temp/tmpe_xfIU.c'
>> cl : Command line error D2003 : missing source filename
>> 
>> Isn't there a better way to check if gcc is used than to actually invoke
>> it? Perhaps only run the test if $CC or $CXX is cc, gcc, or g++? Or even
>> let the user explicitly select a method in the recipe.

>The error message is disturbing.  Skipping the check is probably the
>only way to avoid it (stderr isn't very well supported on MS-Windows).
>
>In the MSVC tool we should be able to tell gcccheck that it doesn't need
>to try.

I agree.

>Making this decision based on the command name is a bit too
>magic for me.  Adding a variable that tells gcccheck to skip the test
>would be possible.  Only problem then is what happens when you switch
>tools.  Well, gcccheck then gets confused anyway, since it's only run
>once...
>
>How about this:
>- init HASGCC and HASGCCXX to empty
>- When gcccheck is invoked it only does the test when HASGCC/HASGCCXX is
>  empty.
>- A tool may change the value of HASGCC and HASGCCXX to skip the test
>  and force a result.
>- You may set HASGCC and HASGCCXX to empty to have the gcccheck run the
>  test again.
>
>A nice effect is that I can remove the hack in test 14 to set $CC to
>"ignore_this" to use the internal dependency checker.  That's an
>indication we are on the right track.
>
>Here is a patch to try out:

[...]

Works like a charm! Along with the changes I made in msvc.py to set
HASGCC/HASGCCXX to "no".

-- 
Be seeing you.



-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3