Ticket #4125 (closed enhancement: wontfix)

Opened 13 months ago

Last modified 7 months ago

add configure option to omit git sha1 from version string

Reported by: ossi Owned by: andrew_b
Priority: major Milestone:
Component: mc-core Version: master
Keywords: Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

when working with git, in particular when using git-rebase extensively, the full rebuild caused by every modification of HEAD quickly becomes a significant time-sink without adding any tangible value.

the attached paths adds an option to suppress this behavior.

Change History

comment:1 Changed 13 months ago by ossi

Ticket #2252 has been marked as a duplicate of this ticket.

comment:2 Changed 13 months ago by zaytsev

Relates to #3603.

comment:3 Changed 13 months ago by andrew_b

  • Status changed from new to accepted
  • Owner set to andrew_b

comment:4 Changed 13 months ago by andrew_b

Branch: 4125_version_no_sha1
Initial changeset:f0e1b6ef35b74588cf8fda759dd005a5679db953

I think, some words should be added to doc/HACKING.

comment:5 follow-up: ↓ 6 Changed 13 months ago by zaytsev

I would be unhappy to see yet another non-default configure option to handle a very specific use case :(

Some options have already been added recently (stuff to inhibit paths, which in my opinion should have gone into --enable-maintainer-mode or something like that), some I think lead to arcane undocumented variables, like the requests of the Debian people who patched manual pages at build time and then complained about packages being non-reproducible because the date is embedded in the manual page (which is exactly right), instead of resetting the file date.

Anyways, there have been constant complaining that the versioning stuff is annoying because of rebuilds for a long time, so I'm unlikely to win the argument against it, but how about the following:

  1. Let us detect version from git if --enable-maintainer-mode is active, otherwise (default) a suffix is appended. I don't think we use maintainer mode for anything special, so it just will have to be added to the release guidelines and CI, and we are all good with sane behaviour per default.
  2. Please make the suffix "dirty", I think this is a common convention for dirty tree builds.

andrew_b, ossi?

comment:6 in reply to: ↑ 5 Changed 13 months ago by ossi

Replying to andrew_b:

I think, some words should be added to doc/HACKING.

i guess so.

Replying to zaytsev:

I would be unhappy to see yet another non-default configure option to handle a very specific use case :(

i don't see a problem with additional options that affect pretty much only the build system.

because the date is embedded in the manual page (which is exactly right)

a bit off-topic, but you're wrong about that - man-pages(7) says it should be the date of the last revision. i suppose a 'clean' filter via gitattributes could do the job of automating it.

  1. Let us detect version from git if --enable-maintainer-mode is active, otherwise (default) a suffix is appended.

i have no problem with coupling it to maintainer mode (though note that the automake manual discourages use of that macro), but it has to be the other way round: the frequent sha1 changes affect developers/maintainers while giving them no tangible benefit, while regular users aren't affected, but really should include the complete version into bug reports, etc.

  1. Please make the suffix "dirty", [...]

yeah, why not.

comment:7 Changed 7 months ago by andrew_b

  • Status changed from accepted to testing
  • Resolution set to wontfix
  • Milestone Future Releases deleted

Let's back to #2252.

comment:8 Changed 7 months ago by andrew_b

  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.