Bug 759712 - Review Request: dragonegg - GCC plugin to use LLVM optimizers and code generators
Summary: Review Request: dragonegg - GCC plugin to use LLVM optimizers and code genera...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jerry James
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-03 11:03 UTC by Eric Smith
Modified: 2014-09-24 03:42 UTC (History)
3 users (show)

Fixed In Version: dragonegg-3.4-2.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-10 18:23:55 UTC
loganjerry: fedora-review+
gwync: fedora-cvs+


Attachments (Terms of Use)

Description Eric Smith 2011-12-03 11:03:14 UTC
Spec URL: http://fedorapeople.org/~brouhaha/dragonegg/dragonegg.spec
SRPM URL: http://fedorapeople.org/~brouhaha/dragonegg/dragonegg-3.0-0.1.rc3.fc16.src.rpm
Description:
DragonEgg is a GCC plugin that replaces GCC's optimizers and code generators
with those from the LLVM project.


Note that this package is for DragonEgg 3.0.rc3 rather than 3.0 final.  This is because the LLVM package in rawhide is currently 3.0.rc3.  I have done private builds of both LLVM 3.0 and DragonEgg 3.0 on Fedora 16, and verified that both work.  I will update the DragonEgg spec for 3.0 final once the rawhide LLVM package is updated.

Comment 1 Eric Smith 2011-12-03 11:13:32 UTC
I've found that DragonEgg 3.0 seems to work fine with the LLVM 3.0.rc3 in rawhide, so I loosened the buildrequires and updated the spec.

Spec URL: http://fedorapeople.org/~brouhaha/dragonegg/dragonegg.spec
SRPM URL:
http://fedorapeople.org/~brouhaha/dragonegg/dragonegg-3.0-1.fc16.src.rpm

Comment 2 Jerry James 2011-12-15 22:55:56 UTC
I tried to build this on a rawhide machine, and got this:
...
+ make -j3
Compiling utils/TargetInfo.cpp
g++: error: directory": No such file or directory
make: *** [TargetInfo.o] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.itjbTr (%build)

Building with "make VERBOSE=1" shows that the g++ invocation includes this: -DREVISION=\"Unversioned directory\".  The shell sees that as two words:
  -DREVISION=\"Unversioned
  directory\"

REVISION is set to that value by svnversion.  So this package cannot be built on a machine where svnversion is installed.

In mock, on the other hand, the build succeeds, since nothing pulls in svnversion, but I see this in the logs:
make: svnversion: Command not found

It looks like REVISION is only used in one source file, src/Backend.cpp, and that the code that uses it is only compiled if IDENT_ASM_OP is defined, and that nothing defines IDENT_ASM_OP.  So I did this in %prep:

sed -i "s/^REVISION:=.*/REVISION:=%{version}/" Makefile

What do you think?

Comment 3 Jerry James 2011-12-16 00:14:33 UTC
I'll take this review.  Quick note: the %defattr in %files is no longer needed.

Also, I had some kind of problem with the gcc versioning.  I tried to install after building:
# rpm -i dragonegg-3.0-1.fc17.x86_64.rpm
error: Failed dependencies:
        gcc = 4.6.2-1.fc17 is needed by dragonegg-3.0-1.fc17.x86_64
# rpm -q gcc
gcc-4.6.2-1.fc17.1.x86_64

Legend:
+: OK
-: must be fixed
=: should be fixed (at your discretion)
N: not applicable

MUST:
[+] rpmlint output:
dragonegg.x86_64: W: spelling-error Summary(en_US) optimizers -> optimizer, optimizes, optimize rs
dragonegg.x86_64: W: spelling-error %description -l en_US optimizers -> optimizer, optimizes, optimize rs
dragonegg.spec:12: W: macro-in-comment %{version}
dragonegg.spec:12: W: macro-in-comment %{release}
dragonegg.spec:19: W: macro-in-comment %{gcc_version}
dragonegg.spec:20: W: macro-in-comment %{gcc_release}
dragonegg.spec:22: W: macro-in-comment %{version}
dragonegg.spec:22: W: macro-in-comment %{gcc_release}
dragonegg.spec:76: W: macro-in-comment %{optflags}
2 packages and 1 specfiles checked; 0 errors, 9 warnings.

Those macros in comments need doubled % signs.
[+] follows package naming guidelines
[+] spec file base name matches package name
[+] package meets the packaging guidelines
[+] package uses a Fedora approved license
[+] license field matches the actual license
[+] license file is included in %doc
[+] spec file is in American English
[+] spec file is legible
[+] sources match upstream: md5sum is 3704d215fb4343040eaff66a7a87c63a for both
[+] package builds on at least one primary arch (tried x86_64)
[N] appropriate use of ExcludeArch:
Question: is llvm available on all arches?
[+] all build requirements in BuildRequires
[N] spec file handles locales properly
[N] ldconfig in %post and %postun
[+] no bundled copies of system libraries
[N] no relocatable packages
[+] package owns all directories that it creates
[+] no files listed twice in %files
[+] proper permissions on files
[+] consistent use of macros
[+] code or permissible content
[N] large documentation in -doc
[+] no runtime dependencies in %doc
[N] header files in -devel
[N] static libraries in -static
[N] .so in -devel: this .so is a plugin, and is in exactly the right place
[N] -devel requires main package
[+] package contains no libtool archives
[N] package contains a desktop file, uses desktop-file-install
[+] package does not own files/dirs owned by other packages
[+] all filenames in UTF-8

SHOULD:
[N] query upstream for license text
[N] description and summary contains available translations
[+] package builds in mock: tried fedora-rawhide-i386
[+] package builds on all supported arches: tried i386 and x86_64
[-] package functions as described: could not test because I could not install; see above
[+] sane scriptlets
[N] subpackages require the main package
[N] placement of pkgconfig files
[+] file dependencies versus package dependencies
[N] package contains man pages for binaries/scripts

Comment 4 Eric Smith 2011-12-16 00:38:53 UTC
Thanks for reviewing this.  I agree with your patch for REVISION, will include it in the next spec, and will report a bug upstream if there isn't one already.

I'll look into the gcc dependency issue with rawhide.  I didn't have that problem when I built the llvm-3.0rc3 and dragonegg packages on F16.  I'll install rawhide in a VM for testing and report back when I have an updated spec and SRPM that fixes it.

I respectfully disagree with changing the macro-in-comment warnings as they are in comments copied directly from the existing gcc-python-plugin spec, and doubled percent signs might be confusing to anyone trying to actually understand the comments.  I'd rather have the rpmlint warnings.  However, if you really feel strongly that those warnings have to be fixed, let me know, and I'll do it.

LLVM is supported on i386 and x86_64, which are the current Fedora Primary Architectures.  The Fedora llvm package spec excludes use of ocaml on s390, s390x, and sparc64, but does not exclude those or any other architectures.  While I have a hard time believing that LLVM will work on all of the Fedora Secondary Architectures, if the LLVM spec doesn't exclude them I don't think the DragonEgg spec needs to either.

Comment 5 Jerry James 2011-12-16 21:02:36 UTC
(In reply to comment #4)
> I respectfully disagree with changing the macro-in-comment warnings as they are
> in comments copied directly from the existing gcc-python-plugin spec, and
> doubled percent signs might be confusing to anyone trying to actually
> understand the comments.  I'd rather have the rpmlint warnings.  However, if
> you really feel strongly that those warnings have to be fixed, let me know, and
> I'll do it.

What I feel strongly about is that the rpm developers should fix their code so that rpm doesn't expand macros in comments. :-)  As long as those macros don't cause any actual problems (and I did not notice any), then I am fine with leaving the comments as they are.

> LLVM is supported on i386 and x86_64, which are the current Fedora Primary
> Architectures.  The Fedora llvm package spec excludes use of ocaml on s390,
> s390x, and sparc64, but does not exclude those or any other architectures. 
> While I have a hard time believing that LLVM will work on all of the Fedora
> Secondary Architectures, if the LLVM spec doesn't exclude them I don't think
> the DragonEgg spec needs to either.

That's fine.  The DragonEgg spec should definitely follow the llvm spec in this regard.  I just wasn't sure if the llvm spec had any ExcludeArch tags, and was too lazy to go look.

Comment 6 Eric Smith 2012-02-06 11:42:45 UTC
The reason you had the dependency problem was that your gcc package ended in .fc17.1.x86_64 but should have been .fc17.x86_64.  I have no idea where that extraneous .1 came from, but what I see in rawhide now is gcc-4.7.0-0.10.fc17.x86_64, which doesn't have that problem.

I *finally* have a working rawhide install.  However, it appears that DragonEgg does not support gcc 4.7 yet, with build failures in src/Backend.cpp.  It looks like this will have to remain on hold until that and any other gcc 4.7 incompatibilities are fixed.

Comment 7 Jerry James 2012-02-06 20:01:43 UTC
The RPM name probably came from somebody doing this: https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Minor_release_bumps_for_old_branches.  While the current Rawhide GCC doesn't have such a trailing number, this could happen again in the future.  You'll need a strategy for dealing with it.

Good luck with gcc 4.7!  I had to fix several of my packages, too.

Comment 8 Eric Smith 2012-02-06 20:18:49 UTC
OK, I hadn't noticed the "Minor release bumps for old branches" in the naming guidelines before.  I'm a little baffled about how that would come about in a rawhide package, but certainly my spec will need to address it.

Comment 9 Eric Smith 2012-06-07 06:57:20 UTC
Rawhide now has LLVM 3.1, and DragonEgg 3.1 mostly supports GCC 4.7 (see the DragonEgg release notes for details), so it's time to try this again.

I have been unable to find any automatic way to deal with "minor release bumps for old branches" for GCC.  There is apparently no way to get the required information at build time in Koji, for reasons stated at the top of the spec file.  Note that this mechanism is copied from the gcc-python-plugin package, which thus has the same problem.  If this actually occurs, it can be dealt with by manually changing the package spec, either turning off the with_hard_gcc_version_requirement flag, or tweaking the value of gcc_vr.

Spec URL: http://fedorapeople.org/~brouhaha/dragonegg/dragonegg.spec
SRPM URL:
http://fedorapeople.org/~brouhaha/dragonegg/dragonegg-3.1-1.fc18.src.rpm
Koji scratch build for Rawhide:  http://koji.fedoraproject.org/koji/taskinfo?taskID=4135197

Comment 10 Jerry James 2012-06-08 22:21:16 UTC
Okay, it looks great.  Bummer about the minor release bumps, thing, but I don't see how to deal with it automatically either.

This package is APPROVED.

Comment 11 Eric Smith 2012-06-08 23:05:43 UTC
New Package CVS Request
=======================
Package Name: mingw-llvm
Short Description: GCC plugin to use LLVM optimizers and code generators
Owners: brouhaha
Branches:
InitialCC:

Comment 12 Gwyn Ciesla 2012-06-09 17:17:52 UTC
Summary and SCM request package manes don't match, please correct.

Comment 13 Eric Smith 2012-06-09 18:51:32 UTC
New Package CVS Request
=======================
Package Name: dragonegg
Short Description: GCC plugin to use LLVM optimizers and code generators
Owners: brouhaha
Branches:
InitialCC:


Sorry about the cut-and-paste error!

Comment 14 Gwyn Ciesla 2012-06-10 14:15:27 UTC
Git done (by process-git-requests).

Comment 15 Fedora Update System 2014-08-30 06:57:12 UTC
dragonegg-3.4-1.el7.2 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/dragonegg-3.4-1.el7.2

Comment 16 Fedora Update System 2014-08-30 07:06:27 UTC
dragonegg-3.4-2.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/dragonegg-3.4-2.el7

Comment 17 Fedora Update System 2014-09-24 03:42:46 UTC
dragonegg-3.4-2.el7 has been pushed to the Fedora EPEL 7 stable repository.


Note You need to log in before you can comment on or make changes to this bug.