> On 17 Oct 2019, at 22:28, Riccardo Mottola via Gnustep-dev
> <gnustep-dev@gnu.org> 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).
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
