cabal sdist runs alex and happy on the maintainers machine #1685

Closed
cartazio opened this Issue Feb 14, 2014 · 8 comments

Comments

Projects
None yet
4 participants
Member

cartazio commented Feb 14, 2014

cabal sdist runs alex and happy on the maintainers machine, and I think that any .y .x files should be processed in the client users side. Otherwise, when a breaking change happens to alex and happy and associated GHC versions, like 7.8, every lib maintainer which has a lib using alex and happy have to prepare a fresh sdist using a newer alex and happy, (they have to do this even if nothing in the code has otherwise changed!!!)

I've hit this with pandoc jgm/pandoc#1136
and others have it it with language-c haskell/c2hs#64#issuecomment-35059925 (which seems to be unmaintained)

Member

cartazio commented Feb 14, 2014

and it says something that both manuel and I find this behavior quite surprising!

Member

23Skidoo commented Feb 14, 2014

See #130. We want to associate metadata with each pre-generated file so that in the preprocess phase we could tell whether the file was produced by an older version of a preprocessor than the one installed.

Member

cartazio commented Feb 14, 2014

@23Skidoo why is it run on the maintainers side rather than the builder's side?

Member

cartazio commented Feb 14, 2014

is this for any module that has preprocessing (eg when I include a suitable pragma for some custom preprocessor), or just certain ones that are "portable" and have special status like Happy and Alex?! Not every preprocessor is system independent!

Member

23Skidoo commented Feb 14, 2014

Yes, it happens only for platform-independent preprocessors.

I think that the main rationale for this feature is bootstrapping (for example, happy's source tree includes .y files and you'd need to have happy installed to install happy without it).

Member

cartazio commented Feb 14, 2014

gotcha

sethfowler referenced this issue in sof/greencard Apr 29, 2014

Closed

Broken on GHC 7.8 #1

greencard is hitting this too, unfortunately.

ttuegel added the duplicate label Feb 28, 2015

Member

ttuegel commented Feb 28, 2015

Duplicate of #130 (literally the oldest issue).

ttuegel closed this Feb 28, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment