(Late followup since I spent most of yesterday working on a cabal-rpm
patch.)
Yaakov Nemoy さんは書きました:
* %buildsubdir is not a common way of doing things
** we need this macro in the install phase to get at the working dir
we used to compile the package.
This is not haskell specific and should really not be needed.
Let's try to get rid of it.
It's needed for the macros that do file detection later on. Once we
cd into the buildroot, we need a way of accessing the old dir we used
to compile the package. Therefore, I've put it in a macro, and both
sets of macros are mandatory. If you have a better solution, please
fix it.
No it is not needed: you could use ${RPM_BUILD_DIR} for that if
necessary (however see also the end of this mail).
But how are packages supposed to get these macros?
Surely each package is not going to include all of
http://ynemoy.fedorapeople.org/haskell/macros.ghc ?
That file is going to be packaged with ghc itself. I've submitted the
following bug.
https://bugzilla.redhat.com/show_bug.cgi?id=460304
Do any other packages (languages) in Fedora provide rpm macros? One of
the things I always liked about fedora is that our spec files are
self-contained unlike some other distros. Are we moving anyway from that?
Also housing the macros in ghc means that if we need to change them then
ghc needs to be rebuild which is a bit expensive - though hopefully that
would be not necessary too often.
The macros are not really that ghc specific: they should be prefixed cabal
not ghc.
Technically no, but I want to differentiate between what the
theoretical command might be for foo haskell compiler, and what
nuances there might be between compilers.
I would prefer just a few macros suitable for cabal that would work
across ghc, hugs, etc, than something very specific to ghc.
IMHO some of it seems to be overkill.
How so? For the most part, i'm converting the work that Bryan has
done into macros, and polished it up. Every step that's there is
stuff that Bryan has decided is necessary.
I created some patches to cleanup cabal-rpm's output. I wish you had
made clear earlier that that was where all this was coming from... if I
had known that I could have cleaned it up much earlier...
As I noted yesterday: I finally tried cabal-rpm and finally realised
where all those macros are coming from. So sorry to Yaakov: it seems
most of my quibbles have actually been with cabal-rpm! ;)
I think I may submit a cabal-rpm package to fedora so that it can be
included.
IMHO a couple of self-contained spec templates are still quite
sufficient for now and that is the way I am inclined to go. Packaging
cabal packages is really not that hard, and to me hiding small
incantation in obscure macros really does not buy use much at all. As
long as packages follow the templates reviews should be just as
straightforward.
- if %ghc_autotools is necessary, can the -p option be made optional?
What should the default be?
Profiling by default? I don't use profile much myself... what do others
think?
I attach an (untested) which cleans up the macro file a bit.
I've attached that to the bug report to add them to GHC.
Thanks. There are still more changes that need to be made though.
> >> * this file detection stuff is scary
> >> ** I've put it into a series of macros and documented it
> Ok, that might be useful. :)
Has anyone other than me tested them though? The filelist macros in the
ghc-X11 review do not work for me, and they seem to be the same as in
the current macros...
I just submitted a patch for it in ghc-X11 review
https://bugzilla.redhat.com/show_bug.cgi?id=426751#c14
now. (Also in my cabal-rpm patches.)
Jens
--
Fedora-packaging mailing list
Fedora-packaging@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-packaging
