Re: [Uhc-developers] Avoiding uuagc-bootstrap
Dear Joachim,
I'd like to respond to the discussion below from half a year ago. Your suggestions have been implemented and from UUAGC version 0.9.42.* the uuagc-bootstrap has become obsolete.
The solution is slightly different from the one you suggested, because our situation is a bit more complicated than that of Happy. AG files can have includes, so a single .hs file can depend on multiple .ag files and parsing the files is needed to figure out all dependencies. Simply putting the .hs files in the place where cabal expects them therefore doesn't work. However, using some smart fiddling with cabal flags solves this.
In version 0.9.42.1, which is now on Hackage, both the AG sources and generated Haskell sources are included. With a standard 'cabal install' the generated Haskell sources are used and UUAGC is build as any simple Haskell library. However, to build from sources you can now do 'cabal install uuagc --ghc-options="-DEXTERNAL_UUAGC"' which of course needs a "uuagc" executable to be available. This will ignore the generated sources and build everything from AG source.
One obvious drawback of this approach is that there is no guarantee that the generated sources in the package can actually be generated from the given AG sources. Also, the generated sources can be different based on the UUAGC version that you use to generate them (i.e. using a newer UUAGC version the generated code can be more efficient but should of course be semantically equivalent). It is the task of the UUAGC developers (which currently pretty much is only me) to make sure these stay in sync, and in practice we will probably use version n to generate the sources for n+1.
Regards,
Jeroen Bransen
Op 8 apr 2012, om 18:47 heeft Joachim Breitner het volgende geschreven:
> Dear Arie,
>
> thanks for your response.
>
> Am Sonntag, den 08.04.2012, 14:09 +0200 schrieb Arie Middelkoop:
>> On 06-04-12 13:52, Joachim Breitner wrote:
>>> when upgradeing uuagc for Debian, I’d like to avoid packaging
>>> uuagc-bootstrap, as it is just a copy of uuagc (right?). Given that
>>> uuagc already exists in Debian, can a new uuagc packages build using
>>> that? If so, how?
>>
>> Let me first say that the package dependencies of uuagc are rather
>> nasty, and that I would be open to suggestions for improvement. The
>> current setup is the best we managed to come up with so far.
>
> have you considered the approach taken by other self-depending programs
> such as happy?
>
> $ cabal unpack happy
> Downloading happy-1.18.9...
> Unpacking to happy-1.18.9/
> $ find happy-1.18.9/dist/
> happy-1.18.9/dist/
> happy-1.18.9/dist/build
> happy-1.18.9/dist/build/happy
> happy-1.18.9/dist/build/happy/happy-tmp
> happy-1.18.9/dist/build/happy/happy-tmp/AttrGrammarParser.hs
> happy-1.18.9/dist/build/happy/happy-tmp/Parser.hs
>
> It ships the generated files in the dist/ directory, i.e. where Cabal
> expects them. This allows Cabal to build happy without using this, but
> also allows the user to easily build directly from source by removing
> the dist/ directory, something that Debian does.
>
>> The 'uuagc-bootstrap' package is indeed some 'stable' copy of the
>> original package, except that it contains the generated sources instead
>> of the original sources, has a different executable name and a different
>> entry-point when used as a library. The last two points are important to
>> prevent collisions when building the actual uuagc package.
>
> I don’t see the advantage over putting the generated sources, together
> with the original sources, in the main uuagc package?
>
>> So, if you want to use an existing uuagc to build uuagc, it's still
>> possible with a slight patch. First, the dependency on the bootstrap
>> package must be removed from the cabal description, but do not add a
>> dependency to an older uuagc to the cabal description! You'll need an
>> existing uuagc somewhere, but that you should be able to express via
>> Debian's package manager.
>>
>> You can then simply put in UUAGC's Main.hs:
>>> main = defaultMainWithHooks (uuagcUserHook' "path-to-old-uuagc")
>>
>> Note: you'll get a deprecation warning because - as mentioned earlier -
>> the preferred method is building via uuagc-as-a-library instead of using
>> a given executable. Anyway, you can ignore this warning.
>
> Thanks, works great. Would it be possible to make this configurable
> using a Cabal flag, so that we don’t have to patch the Cabal and Setup
> file?
>
>> However, I'm not sure what you would gain by doing this. The
>> uuagc-bootstrap package is a conventional haskell package, so it should
>> be easier to handle than fiddling around with an older version of uuagc.
>
> It is an unfortunate misconception in the Haskell world that just
> because it is cheap to upload another package to Hackage, it is also
> cheap for the distributions. For various reasons, every additional
> package causes manual work.
>
> In addition, packaging uuagc-bootstrap in Debian would violate various
> rules and conventions, such as to not have multiple copies of the same
> code package, and also we would not be building uuagc from source (but
> rather from some generated file that supposedly was built from source by
> someone else). The fact that Debian tries hard to build everything from
> source is an important QA measure to guarantee that every user can
> easily fetch the source, modify it, build it and be done. If we were not
> to build the source from source it is likely that actually building from
> source bitrots and will not be possible automatically.
>
> Will it always be possible to build released version n+1 of uuagc with
> version n?
>
> Greetings,
> Joachim
>
> --
> Joachim "nomeata" Breitner
> Debian Developer
> nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
> JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Reply to: