cabal sdist should touch preprocessed .hs files

[simonmar]

cabal sdist for alex is supposed to produce a tarball that builds without requiring Happy, but sometimes it doesn't. The failure is non-deterministic and happens about half the time.

Cabal bundles the Happy-generated .hs files into the source dist, but the problem appears to be that sometimes the timestamp on these files is slightly older than the .y file, so it is ignored when subsequently building the tarball.

For example, here is a correct run:

$ cabal sdist
$ tar tvzf dist/alex-3.1.6.tar.gz --full-time | grep Parser
-rw-r--r-- 0/0            5917 2015-11-30 10:24:29 alex-3.1.6/src/Parser.y
-rw-r--r-- 0/0           42504 2015-11-30 10:24:29 alex-3.1.6/dist/build/alex/alex-tmp/Parser.hs

And an incorrect one:

> tar tvzf dist/alex-3.1.6.tar.gz --full-time | grep Parser    
-rw-r--r-- 0/0            5917 2015-11-30 10:23:43 alex-3.1.6/src/Parser.y
-rw-r--r-- 0/0           42504 2015-11-30 10:23:42 alex-3.1.6/dist/build/alex/alex-tmp/Parser.hs

Here the timestamp on Parser.hs is one second older than Parser.y. If I try to build this tarball without Happy installed, I get this:

$ cabal configure
Resolving dependencies...
[1 of 1] Compiling Main             ( dist/setup/setup.hs, dist/setup/Main.o )
Linking ./dist/setup/setup ...
Configuring alex-3.1.6...
$ cabal build
Building alex-3.1.6...
Preprocessing executable 'alex' for alex-3.1.6...
setup: The program 'happy' is required but it could not be found
[1]    29158 exit 1     cabal build

The fix would appear to be to touch the preprocessed files before packaging the tarball.

[BardurArantsson]

I'm not familiar with how cabal-install does the actual creation of the tarball, but wouldn't it be better to force the proper timestamp during the actual tarring?

[dcoutts]

Note also that cabal unpack does not preserve timestamps.

[hvr]

Duplicate of one-year-old #2311, see also #2362

[hvr]

That's odd... I notice alex.cabal doesn't specify any build-tools dependency on happy, so why is Cabal even allowed to regenerate Happy parsers? It can't possibly know which happy-versions it is allowed to use to begin with. I think that's the real bug here!

We may have multiple issues here:

Cabal needs some way to know which (minimum) happy/alex versions are capable to generate code compatible with certain base versions.

Moreover, Cabal should only generate parsers when build-tools: happy >= x.y && < u.v is specified. In that case, the generated parser MUST NOT be included in the source-tarball, in order for code to be deterministically generated always

In order to support auto-installation of the requested version of happy/alex we may need the new nix-local-store which provides a clean way to properly handle multiple versions of happy/alex installed side by side. (somewhat related to #220)

[phadej]

"Fixed" by #6666