Bugzilla – Bug 203
Need automated RPM package generation
Last modified: 2004-02-23 16:28:03
You need to log in before you can comment on or make changes to this bug.
The current makefiles don't support an install target. Since there is a lack of interest in converting the project to automake, I would at least like the project to generate an RPM package so that installation of binaries on Linux is easier. Currently, using LLVM requires that you know what was built (Debug, Profiled, Optimized) because each installable target ends up in a different directory. This kind of situation needs to be resolved in an RPM package. I'll add this, eventually.
oooh, sounds nice. :)
It may be a bit more work to add automake support than just a simple rpm target... But IMO automake would be a better solution: automatic distribution tarfiles, hooks for testing before creating a release, install targets, srcdir != builddir builds that will finally work (not everything under llvm/test works right now). Granted that these features will not help developers that much (other than the fact that Makefile.am are going to be much simpler than todays Makefiles) but it will simplify releases, user experience and integration with other projects. Since automake provides an install target with DESTDIR support, rpm creation (or deb, gentoo ebuild or freebsd port) can be trivially added.
Bug 106 discusses using automake with LLVM. I think that Reid would definitely agree with you that automake is a good thing :) I think that the final decision was that converting all of LLVM over to using automake (including test/Programs) would be a huge amount of work (and be potentially destabilizing), that provide marginal amounts of actual value. That said, we're not totally precluding it from ever happening, it's just that there are so many other things that we can work on... :) -Chris
You're preaching to the choir. I'd rather see the project move to automake too. But, the people's who's opinions count didn't respond so I assumed there was no interest. I attempted it by myself but the structure of LLVM is not automake friendly (lots of special rules in makefiles and directory reorganization required). Moving to automake would be a significant change. See bug 106 for the details. I agee that the benefits out-weigh the costs but its a little pointless to do if the main people on the project (especially the build maintainer) don't agree. So, we'll just have to build the *same* automake functionality piecemeal. <sigh>
The current Makefiles do indeed support 'install' targets -- at least, they do now. An rpm specfile would be nice.
The current install target does not support DESTDIR which will complicate the rpm specfile. If it is not a big change it will be really nice to have.
I added part of the DESTDIR stuff earlier today, but your message reminded me of a part that I forgot. Anyway, here's DESTDIR: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040119/010901.html http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040119/010906.html Now you should be able to say 'gmake DESTDIR=/blah/blah/blah/ install' and it should do the right thing; I haven't tested this yet.
Created an attachment (id=77) [details] LLVM spec file I'm working on an llvm spec file. A current draft is enclosed (I have a test "rpmbuild -bb" running right now, so it may not be 100% happy yet!!) Nevertheless, if you have nits to pick, pick them now.
Ok, the RPM spec file has been checked in (after having noted that it is possible to build an llvm RPM with it.) http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040209/011410.html This RPM specfile does not install bytecode-libs. I am not sure exactly where they should go (but I don't think it impacts upon whether or not an RPM spec file may exist.) Traditionally they have been installed in the same install tree as llvm-gcc, although they are built by 'make runtime' in the llvm tree. John Criswell had a good point when he mentioned the other day that it'd be nice to split the runtime libraries off from the main tree. So I'm going to leave this aside for the moment, pending further discussion.
Confirmed. The header files are now installed properly. One thing I noted is that the path I need to use to #include the llvm library headers is: #include <llvm/llvm/header.h> This seems a little awkward with the duplicate llvm but its not a big deal. Marking this as verified.
Oops, my last comment posted to the wrong bug. Please ignore.
I looked at the initial RPM spec file that Brian produced. It looks fine as a starting point but I have a couple concerns: 1. There isn't any error checking during build/install phases 2. This is intended for a source distribution that gets compiled. Wouldn't it be easier and more effective to make a binary distribution for the RPM? 3. I'm not sure the root of the source tree is the best place for llvm.spec. You might want to place it in autoconf? 4. It depends on llvm-gcc being available which isn't good. Either llvm-gcc needs to be distributed with LLVM, you need an llvm-gcc.spec file for that package or (preferably), combine both llvm-gcc and llvm into a single binary distribution. Reid.
> 1. There isn't any error checking during build/install phases I'm not sure what you mean by this - if the make fails, the RPM build will fail, and if the install exits with an error, the RPM build will also fail. >2. This is intended for a source distribution that gets compiled. Wouldn't it be > easier and more effective to make a binary distribution for the RPM? The RPM build process is designed to produce both binary distributions (llvm*.i386.rpm; what an end user would install) and source distributions (llvm*.src.rpm; what a system integrator would want to use). The RPM spec file simply describes the build process to rpmbuild; it takes care of the creation of the binary RPM and the source RPM. The source RPM can, in turn, be used to regenerate the binary RPM. I think this is the common case of RPM usage. >3. I'm not sure the root of the source tree is the best place for llvm.spec. You > might want to place it in autoconf? I think, though I am not certain, that having it be at the root of the tree is necessary for the rpmbuild -ta/-tb/-ts/... options to work (though I would be happy to be proven wrong). >4. It depends on llvm-gcc being available which isn't good. Either llvm-gcc > needs to be distributed with LLVM, you need an llvm-gcc.spec file for that > package or (preferably), combine both llvm-gcc and llvm into a single binary > distribution. We can't combine llvm and llvm-gcc into a single distribution for licensing reasons, I believe. I think making an llvm-gcc spec file is a good idea. I haven't had the time to address that yet. I agree that it is not as good as it could be, but this is a first step.
Bug 230 and Bug 231 describe our ideas for how we want to package llvm-gcc and the runtime, eventually (time permitting!) Basically, we want to be able to have three RPMs: llvm-tools, llvm-runtime, and llvm-gcc. llvm-gcc can BuildDepend on llvm-tools; llvm-runtime can BuildDepend on llvm-gcc and llvm-tools.
I think I have addressed all your concerns. If you have further comments about llvm packaging issues in general, please summarize them in another bug (for llvm-gcc and the runtime, see Bug 230 and Bug 231 respectively; otherwise, please feel free to open another bug.)