[commit: ghc] master: add $(CrossCompilePrefix) to hp2ps (#7639) (b0fad0c)

[Gabor Greif]

On 2/4/13, Simon Marlow <marlowsd at gmail.com> wrote:
> On 04/02/13 11:52, Gabor Greif wrote:
>> Hi Simon, all,
>>
>> here is me my new patch:
>>
>> $ git show 95303e2b96f0630a051544b216cf4530d37dbaba
>> commit 95303e2b96f0630a051544b216cf4530d37dbaba
>> Author: Gabor Greif <ggreif at gmail.com>
>> Date:   Fri Nov 23 17:54:00 2012 +0100
>>
>>      Allow different customizations per cross target
>>      by obtaining CrossCompilePrefix from mk/config.mk and
>>      using that to include mk/$(CrossCompilePrefix)build.mk
>>      instead of mk/build.mk when present.
>>
>> diff --git a/mk/custom-settings.mk b/mk/custom-settings.mk
>> index e64bb36..8de3450 100644
>> --- a/mk/custom-settings.mk
>> +++ b/mk/custom-settings.mk
>> @@ -5,7 +5,8 @@ ifeq "$(Validating)" "YES"
>>   include mk/validate-settings.mk
>>   -include mk/validate.mk
>>   else
>> --include mk/build.mk
>> +CrossCompilePrefix := $(word 3,$(shell grep -e "^CrossCompilePrefix
>> *= " mk/config.mk))
>> +-include $(firstword $(wildcard mk/$(CrossCompilePrefix)build.mk)
>> mk/build.mk)
>>   endif
>>
>>   ifeq "$(BINDIST)" "YES"
>>
>
> Sorry, but that's yucky! (the shell/grep hack)

Yep it is yucky :-/

>
> I don't get it - custom-settings.mk looks like it is always included
> after config.mk to me.  It's supposed to be, because build.mk can
> override settings in config.mk.

Ha! it is included from two places:

$ git grep custom-settings.mk
Makefile:include mk/custom-settings.mk
ghc.mk:include mk/custom-settings.mk
mk/validate-settings.mk:# override these.  See also mk/custom-settings.mk.

I am talking about the first one, you about the second. In both cases
mk/config.mk is included, so we are good.

Turning on "$(warning ...)"-style debugging, I see that when
building a cross-compiler CrossCompilePrefix is correctly set,
with exception of phase=0, when it is empty. This turns out to
disturb the names of the registered libraries.
My solution is to create a new make variable GlobalCrossCompilePrefix
which does not vary with the phase and use that.

New (simplified) patch below. I'll commit if there
is no complaint by Friday.

Cheers,

    Gabor


$ git show 5830ceeb6164e3ab24455474ed65e4d5fc129c94
commit 5830ceeb6164e3ab24455474ed65e4d5fc129c94
Author: Gabor Greif <ggreif at gmail.com>
Date:   Fri Nov 23 17:54:00 2012 +0100

    Allow different customizations per cross target
    by obtaining GlobalCrossCompilePrefix from mk/config.mk and
    using that to include mk/$(GlobalCrossCompilePrefix)build.mk
    instead of mk/build.mk when present.

    Note: GlobalCrossCompilePrefix is basically the same
          as CrossCompilePrefix, but does not depend on $(phase).

diff --git a/mk/config.mk.in b/mk/config.mk.in
index e40f569..566bd19 100644
--- a/mk/config.mk.in
+++ b/mk/config.mk.in
@@ -571,6 +571,7 @@ GHC_PACKAGE_DB_FLAG = @GHC_PACKAGE_DB_FLAG@

 WhatGccIsCalled       = @WhatGccIsCalled@
 GccVersion            = @GccVersion@
+GlobalCrossCompilePrefix = @CrossCompilePrefix@
 ifeq "$(phase)" "0"
 CrossCompilePrefix    =
 else
diff --git a/mk/custom-settings.mk b/mk/custom-settings.mk
index e64bb36..e5e564c 100644
--- a/mk/custom-settings.mk
+++ b/mk/custom-settings.mk
@@ -5,7 +5,7 @@ ifeq "$(Validating)" "YES"
 include mk/validate-settings.mk
 -include mk/validate.mk
 else
--include mk/build.mk
+-include $(firstword $(wildcard
mk/$(GlobalCrossCompilePrefix)build.mk) mk/build.mk)
 endif

 ifeq "$(BINDIST)" "YES"



>
> Cheers,
> 	Simon
>
>
>>
>> This solution falls back to using mk/build.mk when building a cross
>> compiler and
>> mk/<my-cross-target>-build.mk is not present. A slight complication is
>> that when
>> mk/custom-settings.mk (the above file) get included from Makefile the
>> mk/config.mk
>> is not included (it gets read from the recursive make invocation by
>> mk/ghc.mk). So
>> I simply fish for CrossCompilePrefix with a grep line, but nothing bad
>> happens when
>> it is not found.
>>
>> Okay to commit? Improvement suggestions? I'll add some lines of
>> documentation if
>> you think this is good to go.
>
>
>