Re: make error in base on Solaris

[Richard Frith-Macdonald]

> On 17 Oct 2019, at 22:28, Riccardo Mottola via Gnustep-dev <address@hidden> 
> wrote:
> 
> Stefan Bidigaray wrote:
>> Ah... Sorry about that. When I looked at your original email this morning I 
>> saw the config.status line and just assumed that's where the error was 
>> coming from.
> 
> --trace was of help
> 
>> 
>> So it looks like the file comparison options of test are not portable. The 
>> Heirloom project's sh, for example, does not provide it. [1]
>> 
>> The code in line 105 is quite old, so I'm surprised you haven't run into 
>> this problem before. Git blame says it's 5 years old [2].
> 
> It is! to be honest, I remember to have seen this problem before, but I never 
> experienced it "hard blocking" like today.
> I think I was used to always to a clean build or run configure manually, in 
> that case it disappears.
> 
> Your cited manpages shows the options I have on Solaris, apparently.
> 
>>    I wonder how it can be made more portable. Or, having bash, if I
>>    can run
>> 
>> 
>> Maybe the solution is to simply revert this particular change? The old code 
>> in this section of the Makefile looks reasonable. Honestly, I do not 
>> understand why we would use the "-nt" options in a Makefile, to begin with. 
>> The purpose of the make utility is exactly to run commands based on the age 
>> of the files' dependencies, so why would we do this manually with shell 
>> commands?
>> 
> 
> Exactly - the goal of make is itself timestamp dependency, so I don't get 
> that part of the patch, maybe it can be partially reverted. Or it was some 
> strange kind of workaround?
> 
> It is of Yavor, but Richard applied, maybe he can chime in to the discussion.

The idea here (explained in the commnt) is to avoid lengthy unnecessary 
reconfigurations:

# If the generated makefiles are present but their prerequisites have
# changed, let config.status regenerate them.  This is much faster and
# equally safe than running configure again, provided that configure
# has not been modified.

So the choice here is to do a full (slow) configure if the version has changed, 
but otherwise do a fast reconfigure, and it looks like a good idea (saving 
quite a bit of time).


The current rules say:

base.make: config.status base.make.in Version
# If Version is newer than the target, configure must be rerun so that
# its variables get AC_SUBST'ed and actually updated in base.make.
        @if [ Version -nt $@ ]; then ./configure; else ./$< $@; fi

I think the reason for this code is that one target (base.make in this case) 
can only have one 'recipe' to build it, so the recipe makes a decision about 
what to do based on the age of Version.

However, gnu-make (I'm not an expert,  just reading the documentation) allows 
double-colon rules, where you can huve multiple rules for a target each with a 
separate recipe (as long as there are no single colon rules for the same 
target).
So it might be possible to change this code to

base.make:: Version
        ./configure

base.make:: config.status base.make.in
        ./$< $@

However I don't know whether that would cause dependency issues (eg the first 
rule creates a config.status, and then the second rule gets applied as well).