f



git + autofail = exciting new build disasters!

I'm presently trying to build a auto* package cloned from a git
repository. This package is 100% identical to one which can be built,
however, autowontdothat won't let because
git-handles-timestamps-correctly !!25 has chosen to change the original
file timestamps such that the generated Makefile insists on
re-autothrowupping the other autocrap excrements because it wrongly
believes something was changed there.

When geniusses collide ...
0
Rainer
10/14/2016 5:58:22 PM
comp.unix.programmer 10848 articles. 0 followers. kokososo56 (350) is leader. Post Follow

10 Replies
573 Views

Similar Articles

[PageSpeed] 15

On 2016-10-14, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> I'm presently trying to build a auto* package cloned from a git
> repository. This package is 100% identical to one which can be built,
> however, autowontdothat won't let because
> git-handles-timestamps-correctly !!25 has chosen to change the original
> file timestamps such that the generated Makefile insists on
> re-autothrowupping the other autocrap excrements because it wrongly
> believes something was changed there.

See my answer to:

http://stackoverflow.com/questions/33278928/how-to-overcome-aclocal-1-15-is-missing-on-your-system-warning-when-compilin/37669184

Basically go into the Makefile and substitute dummy success commands
for the masturbatory AutoFuckme invocations.

In my answer, I use GNU Awk as the example, and get it to build in spite
of it wanting a full installation of AutoTrump due to correct
git timestamps.
0
Kaz
10/14/2016 6:48:00 PM
Kaz Kylheku <221-501-9011@kylheku.com> writes:
> On 2016-10-14, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> I'm presently trying to build a auto* package cloned from a git
>> repository. This package is 100% identical to one which can be built,
>> however, autowontdothat won't let because
>> git-handles-timestamps-correctly !!25 has chosen to change the original
>> file timestamps such that the generated Makefile insists on
>> re-autothrowupping the other autocrap excrements because it wrongly
>> believes something was changed there.
>
> See my answer to:
>
> http://stackoverflow.com/questions/33278928/how-to-overcome-aclocal-1-15-is-missing-on-your-system-warning-when-compilin/37669184
>
> Basically go into the Makefile and substitute dummy success commands
> for the masturbatory AutoFuckme invocations.
>
> In my answer, I use GNU Awk as the example, and get it to build in spite
> of it wanting a full installation of AutoTrump due to correct
> git timestamps.

The problems is the git timestamps are not correct, not even for the git
definition of that: Files created by the same git clone should have the
same timestamp in this situation, however, at least on ext4 (nanosecond
support), they don't.
0
Rainer
10/14/2016 7:46:21 PM
On 2016-10-14, Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Kaz Kylheku <221-501-9011@kylheku.com> writes:
>> On 2016-10-14, Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>> I'm presently trying to build a auto* package cloned from a git
>>> repository. This package is 100% identical to one which can be built,
>>> however, autowontdothat won't let because
>>> git-handles-timestamps-correctly !!25 has chosen to change the original
>>> file timestamps such that the generated Makefile insists on
>>> re-autothrowupping the other autocrap excrements because it wrongly
>>> believes something was changed there.
>>
>> See my answer to:
>>
>> http://stackoverflow.com/questions/33278928/how-to-overcome-aclocal-1-15-is-missing-on-your-system-warning-when-compilin/37669184
>>
>> Basically go into the Makefile and substitute dummy success commands
>> for the masturbatory AutoFuckme invocations.
>>
>> In my answer, I use GNU Awk as the example, and get it to build in spite
>> of it wanting a full installation of AutoTrump due to correct
>> git timestamps.
>
> The problems is the git timestamps are not correct, not even for the git
> definition of that: Files created by the same git clone should have the
> same timestamp in this situation, however, at least on ext4 (nanosecond
> support), they don't.

You mean the update should behave as if all the files which changed
are identified and the subject to "touch --r one-of-them {all/rest}-of-them ...".
so that they all have a new timestamp, but exactly the same one?
That sounds reasonable.
0
Kaz
10/14/2016 8:16:41 PM
> > Basically go into the Makefile and substitute dummy success commands
> > for the masturbatory AutoFuckme invocations.

Purchase the 2017 model of the exciting new Turbomake! It goes from zero to 
smoking wreck in 5.94 seconds!

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.
'I desire mercy, not sacrifice.'
If you assume the final scene is a dying delusion as Tom Cruise drowns below
the Louvre, then Edge of Tomorrow has a happy ending. Kill Tom repeat..
0
Siri
10/14/2016 9:54:11 PM
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>
> The problems is the git timestamps are not correct, not even for the git
> definition of that: Files created by the same git clone should have the
> same timestamp

No, this is not the git definition. The git definition is to leave
the timestamps as generated by the system and to not modify them.
What you have probably in mind is the behaviour of "git archive".

Your options are:

1. For a one-shot clone:
Use git archive and unpack that archive over your git tree.
This will set the timestamps as you conjectured.

If you checkout from e.g. github just for the purpose of
building, you should better not clone the repository at all
but just use the archive tarballs anyway:
This way your problem should not occur at all.

OTOH, if you clone the package for being a co-author of it, you
should probably have the required autotools versions anyway,
and so you shouldn't have a problem, either. (Unless the
upstream package is broken in which case it should be fixed...)

2. If you can convince upstream:
Put AM_MAINTAINER_MODE into configure.ac

This restores the original role of ./configure as a file
to be shipped so that the user can compile without
autotools being installed. I never understood why autotools
upstream thinks that the default of an enabled _maintainer_ mode,
which cannot even be disabled by the user, is a great idea:
This just contradicts the main purpose of autotools to ship
the ./configure file to the user.
The above misnomer of the macro indicates already the brokenness
of this idea, because using AM_MAINTAINER_MODE just "repairs"
the broken default and actually _disables_ maintainer mode
by default.

Perhaps you are lucky, and a misguided upstream "just" used
AM_MAINTAINER_MODE([enabled]) which "just" picks the wrong
default: In this case, you can call ./configure at least with
--disable-maintainer-mode

3. Put some hooks into .git which will checkout with
whatever timestamp policy you prefer.

4. Manually touch all files, using e.g. --reference if
you have GNU touch, or manually taking care of the order.
0
Martin
10/15/2016 12:01:40 PM
Martin Vaeth <martin@mvath.de> writes:
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>
>> The problems is the git timestamps are not correct, not even for the git
>> definition of that: Files created by the same git clone should have the
>> same timestamp
>
> No, this is not the git definition. The git definition is to leave
> the timestamps as generated by the system and to not modify them.

More precisely: git doesn't version file metadata. With regards to
timestamps, this has been praised as "the Right way of handling this"
here a couple of times. Like all "Right" ways, they happen to work for
whatever their disciples happen to do and - like all disciples - these
gleefully claim that whatever problem their "Right" solution cannot
handle is just not a proper problem.

For the given case, ignoring the issue doesn't cause problems if and
only if no file that is in the repository could also be generated by a
make rule based on other files which are also in the repository. If this
isn't given, the behaviour upon invoking make is essentially random.

[...]

> Your options are:
>
> 1. For a one-shot clone:
> Use git archive and unpack that archive over your git tree.
> This will set the timestamps as you conjectured.

I wasn't conjecturing what you conjectured I were conjecturing. I've
just noted that git clone breaks make by causing file mtimes to change
randomly regardless of actual file modifications.

> If you checkout from e.g. github just for the purpose of
> building, you should better not clone the repository at all
> but just use the archive tarballs anyway:
> This way your problem should not occur at all.

Indeed. Not using git neatly avoids any problems git behaviour might
otherwise cause. Who needs source code management, anyway!

> OTOH, if you clone the package for being a co-author of it, you
> should probably have the required autotools versions anyway,
> and so you shouldn't have a problem, either. (Unless the
> upstream package is broken in which case it should be fixed...)

As usual with auto*, the people who use it aren't really aware of what
it actually does and autoreconf merrily re-generates the build system
based on the installed auto* version. But there should be no need to
have any version of auto* installed unless the files it works with
actually need to be modified.

[...]

> Put AM_MAINTAINER_MODE into configure.ac

[...]

> AM_MAINTAINER_MODE

[...]

> _disables_ maintainer mode

Considering this, I'm I correct in concluding that

AM_INIT_AUTOMAKE

cleanly exits automake, that

AM_SILENT_RULES

enables verbose mode and that

AM_CONDITIONAL

unconditionally executes something?

Or is this "however the wind blew the day the macro happened to be
implemented"?

[...]

> 3. Put some hooks into .git which will checkout with
> whatever timestamp policy you prefer.

Not really useful as hooks have to be set up manually for each
repository.

Someone suggested some equivalent of

find -type f | while read x; do touch -d @`git log -1 --format=format:%ct $x` $x; done

But it's entirely sufficient to simulate transaction semantics by
setting the times of all files which were 'logically' created at the
same time to the same time.

0
Rainer
10/15/2016 1:19:37 PM
Rainer Weikusat <rweikusat@talktalk.net> wrote:
> Martin Vaeth <martin@mvath.de> writes:
>>
>> No, this is not the git definition. The git definition is to leave
>> the timestamps as generated by the system and to not modify them.
>
> More precisely: git doesn't version file metadata. With regards to
> timestamps, this has been praised as "the Right way of handling this"
> here a couple of times.

I didn't judge it but just formulated what is the matter of state.
Actually, I do not agree with this "praising".
In fact, for some projects I had written scripts which collect the
metadata in some auxiliary file and restore the metadata from that
file. I think, meanwhile there are also some public projects out
there which do a similar thing and which can be used through hooks.

>> 1. For a one-shot clone:
>> Use git archive and unpack that archive over your git tree.
>> This will set the timestamps as you conjectured.
>
> I wasn't conjecturing what you conjectured I were conjecturing.

This was just meant to be a reference to what you obviously called
the "git definition".

> Indeed. Not using git neatly avoids any problems git behaviour might
> otherwise cause. Who needs source code management, anyway!

Source code management is one thing and cloning a repository
just for the purpose of compiling is another. I am just trying
to say: Use what is appropriate for what you are doing.

> As usual with auto*, the people who use it aren't really aware of what
> it actually does and autoreconf merrily re-generates the build system
> based on the installed auto* version.

Not really: The build system can be rather precise in the versions which
are supposed to be used for eautoreconf. For instance, one can have
AUTOMAKE_OPTIONS in Makefile.am, AC_PREREQ, AM_GNU_GETTEXT_REQUIRE_VERSION
in configure.ac, etc.

> But there should be no need to have any version of auto* installed
> unless the files it works with actually need to be modified.

If you are developing a package (which I suppose you are doing
if you have a need for source-code management for it) then sooner
or later you will modify one of these files.

Actually, it is strange if a _repository_ contains a ./configure
script and other scripts which can be generated by autotools:
This is exactly why there is (and should be) a separation between
the repository (meant for developers) and the distributed tarball
(meant for users who essentially want to compile/install the package).
This is why I had suggested that for the first installation
(especially if you are not sure whether you have the appropriate
autotools versions) you should unpack the tarball over the repository.

>> AM_MAINTAINER_MODE
>
> [...]
>
>> _disables_ maintainer mode
> [...]
>
> Or is this "however the wind blew the day the macro happened to be
> implemented"?

As mentioned, this misnomer comes from the IMHO bad choice
of the defaults: which are some uncondtional use of maintainer mode.

What AM_MAINTAINER_MODE actually means is that _instead_ of
that bad default there will be injected code (in configure and the
generated makefile) which can switch maintainer mode on _or_ off;
the argument of AM_MAINTAINER_MODE specifies then whether in this
_new_ injected code the (new) default is on or off. If no argument
of AM_MAINTAINER_MODE is specified, this new default is off.

So, actually, AM_MAINTAINER_MODE *would* have a sensible meaning
if the default (without AM_MAINTAINER_MODE) would be sane
(i.e. code which has no maintainer mode - as opposed to code which
actually even has a _forced_ maintainer mode).

What is wrong here is really the default, i.e. what is done
if AM_MAINTAINER_MODE is not specified. If that default would
be the opposite, then the naming of AM_MAINTAINER_MODE would
completely make sense.

I am quite sure that this was the original intention of
AM_MAINTAINER_MODE until somebody had the "great" idea to
make the bad behaviour the default...

You can see the effect in misguided postings as these:

https://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-is-not-cool/

Why am I not surprised that this postings is from a developer
in the GNOME project?

>> 3. Put some hooks into .git which will checkout with
>> whatever timestamp policy you prefer.
>
> Not really useful as hooks have to be set up manually for each
> repository.

Not really: man core.hooksPath

> Someone suggested some equivalent of
>
> [...] touch -d @`git log -1 --format=format:%ct $x` [...]

For instance. There are various corresponding hook scripts in
the net which do this automatically for you.
However, although this might be nice at the _very first_ cloning,
this is usually not very convenient when you checkout single
files later on. That's why I meant: You have to use scripts
to implement your _personal_ favorite timestamp policy, since
every policy has some disadvantages...

> But it's entirely sufficient to simulate transaction semantics by
> setting the times of all files which were 'logically' created at the
> same time to the same time.

The problem here is that, in general, what is "logically" created
at the same time depends on what you want to do. If you do your
"git merge/checkout/pull" and have already some of the freshly
"written" files in that directory (possibly under a different
name if they just need to be renamed) - then these files are
"logically" created at the same time from one point of view but
not from another point of view: Resetting the new file stamps
to the old filestamps is as false as updating the old file stamps
although the files did not change.
Even in such simple cases, operations like "git pull" are naturally
not atomic. Sure, there might be cases (e.g. when you are in an empty
directory) when it is "natural" to consider "git pull" as an
atomic operation, but this case distinction would make git even
more complex.
Nevertheless, if you know a good way to handle and implement it,
I would suggest to submit a patch to git upstream...
0
Martin
10/15/2016 4:11:58 PM
Martin Vaeth <martin@mvath.de> writes:
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>> Martin Vaeth <martin@mvath.de> writes:

[...]

>>> 1. For a one-shot clone:
>>> Use git archive and unpack that archive over your git tree.
>>> This will set the timestamps as you conjectured.
>>
>> I wasn't conjecturing what you conjectured I were conjecturing.

[I just noticed that the git default policy breaks make]

> This was just meant to be a reference to what you obviously called
> the "git definition".

The idea behind this is that file in different git repositories are
really different files, not just 'working copies' of some 'master file'.
With regards to timestamps, this may have advantages in certain
situations (other people mentioned some in the past). But that a newly
cloned repository will contain files created at different times, thus
giving the impression that some of them are newer than others, is just
an artefact of the way these files are created.

>> Indeed. Not using git neatly avoids any problems git behaviour might
>> otherwise cause. Who needs source code management, anyway!
>
> Source code management is one thing and cloning a repository
> just for the purpose of compiling is another.

To quote myself:

	Like all "Right" ways, they happen to work for whatever their
	disciples happen to do and - like all disciples - these
	gleefully claim that whatever problem their "Right" solution
	cannot handle is just not a proper problem.

You're free to consider "storing source code and modification history
readily accessible on some server" (so that it can be installed and used
in some way on different computers or by different people) "not source
code management" but I don't.

[...]

>>> 3. Put some hooks into .git which will checkout with
>>> whatever timestamp policy you prefer.
>>
>> Not really useful as hooks have to be set up manually for each
>> repository.
>
> Not really: man core.hooksPath

[rw@duesterwald]/tmp/suricata $whatis core.hooksPath
core.hooksPath: nothing appropriate.
0
Rainer
10/15/2016 5:15:28 PM
Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>
>> Not really: man core.hooksPath
>
> [rw@duesterwald]/tmp/suricata $whatis core.hooksPath
> core.hooksPath: nothing appropriate.

https://github.com/blog/2188-git-2-9-has-been-released

: You can now specify a custom path for hooks. Git calls hook
: scripts to allow you to implement custom policy or actions
: when certain events occur. These hook scripts are found
: inside the .git directory of each repository, making them
: a pain to manage if you have a standard set of hooks for
: all of your repositories. Now you can store the hooks in
: one place and point all of the repositories at them with
: the new core.hooksPath config.
0
Martin
10/15/2016 8:46:38 PM
Martin Vaeth <martin@mvath.de> writes:
> Rainer Weikusat <rweikusat@talktalk.net> wrote:
>>>
>>> Not really: man core.hooksPath
>>
>> [rw@duesterwald]/tmp/suricata $whatis core.hooksPath
>> core.hooksPath: nothing appropriate.
>
> https://github.com/blog/2188-git-2-9-has-been-released

For 'other, technical reasons', the version of git I'm presently using
is based on 1.7.3.2.

0
Rainer
10/16/2016 8:00:22 PM
Reply: