Yaakov (Cygwin/X) wrote:
> On 05/07/2009 23:29, Dave Korn wrote:
>> Just CPP, as far as I noticed. It could well be a bug.
>
> I suspect so. Autoconf does consider CPP to be a recognized override.
>
>> Hmm. I think a problem is that there's no way you can make your default
>> setting be "${CC} -E" and have it get automatically recalculated / deferred
>> evaluation in the even that something subsequently recalculates CC, is there?
>>
>> I'm not sure I can see anything useful to do about it. Maybe just omit
>> the
>> CPP (and CXXCPP) definitions, on the ground that they will always be inferred
>> from "$(CC) -E" anyway?
>
> Looking at AC_PROG_CPP, it AC_REQUIRE(AC_PROC_CC) and defaults to "$CC
> -E" unless CPP is defined. So we can just set CC and it should DTRT;
> I'll commit a patch shortly.
Well, not exactly, surely the *right* thing to do is what autoconf does:
test "$(CC) -E", then test "$(CC) -E -traditional-cpp", then finally try
"/lib/cpp"; *any* constant value that you set it to bypasses checking.
My real concern is what I said in the other thread. Exported shell
variables interact badly with recursive makes. If a makefile does something
to the value of $(CC) and then recursively invokes a submake, it might expect
the value of $(CC) in the recursive submake to be the value it has just set,
and indeed it will be - unless there's an exported CC in the environment, then
that will override it - unless again the recursive submake invocation
explicitly writes "$(MAKE) CC=$(CC)" on the commandline.
In fact, this is probably what might be considered a bug in GCC's makefile,
as it passes down CC on the commandline but not CPP. But then again it
doesn't have a definition for CPP, it wants the search to be performed, and it
doesn't know there's an environment definition there to interfere. Should
GCC's top-level makefile really have to defensively declare and pass down a
variable it doesn't actually want to use or have anything to do with, just in
case someone has set it in the environment? Ow. Recursive makes are bad.
> > And perhaps you should omit CPPFLAGS and LIBS as
>> well; what benefit can there be in supplying an empty default?
>
> Some packages need to force an addition to these; declaring and
> exporting them makes it much easier to modify them when necessary.
Huh? "Easier"? I must not be following you. How is it easier to write
variable=value
in a package's .cygport script just because the variable was already defined
and exported in the main cygport script? Is this something to do with the
class structure in cygport?
cheers,
DaveK
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
Cygwin-ports-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
