On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards instead of listing all the sources" and then wrote in response to my reply:> On Sun, Oct 10, 2004 at 04:40:48PM -0700, Reid Spencer wrote: > > http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards > > > > is your answer. > > I think their "answer" is lame; we have already sacrificed portability > because we are using enough of gmake-only functionality because we > cannot depend on the system "make" being anything useful, yet gmake is > portable, and hence, the "standard".I agree completely.> The thing about "distribute only what you list", well... maybe, but the > way "WE" do distribution is (I believe) checkout, build, test, make > clean, make dist. That way, you *know* that what you're distributing > actually works. But I'm not the distro person, that's John. :)Well, automake changes all that. Right now it takes John 1-2 weeks to do a "distro". automake can produce a VALIDATED distribution automatically with only CPU time involved. The "distcheck" target builds a distribution candidate, produces a tar.gz of it, unpacks it, rebuilds it, and if everything is okay, the tar.gz is good to go. This will find ALL KINDS of subtle errors and a big part of getting the distribution right is setting up the _SOURCES variables to list things correctly. There's some other points not mentioned in the automake documentation. (1) It turns out to be incredibly handy to have control over what actually gets built when you're doing multi-platform stuff. You can add files to directories that WON'T be compiled by anyone until you commit changes to the Makefile.am. This allows me to commit stuff on one platform, check it out on another, and another, and ..., build them all and only modify the Makefile.am when its working everywhere. (2) Despite (1) above, we'll probably try to figure out a wildcard approach for directories that are strictly portable. I.e. we'll keep the list of files for lib/System and anything else that needs to be tested on multiple machines but use a wildcard in the places that are pure/vanilla C++ and a check-in on one platform is pretty much guaranteed to work everywhere. (3) Another thing you'll run into is the FINDPATH macro function in the Makefile.rules.am. This is a hack currently implemented for simplicity in the tools/*/Makefile.am files. What we eventually want to do is put all the libraries into one directory and use a -L option to find them. (4) We've recently discovered that executable size is about 1/2 with automake build. This might be due to the use of -O2 option, but since its mostly debug output in the executables, this is unlikely. There was probably an error in the existing makefiles that duplicated the debug info (just guessing). (5) Automake isn't a panacea, it has its warts like anything else. I just happen to think that the benefits out weigh the costs. We get perfect installs, simplified distribution builds (everyone can do it), automated testing ("make check"), perfect dependency generation, etc. As for warts, you've already asked the most frequently raised objection (listing source files). There are a few others, like RANLIB (can't override it on a per-target basis). To me, these are small price to pay for the benefits. There aren't many other things that automake doesn't do exceptionally well. In any event, this is all a grand experiment. We're doing this to see if it is (a) possible, (b) worthwhile to convert to automake. We need to make a list of pros and cons and that can only be done after people have tried it and used it for a while. Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041010/dc750731/attachment.sig>
Reid Spencer wrote:> On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards > instead of listing all the sources" and then wrote in response to my > reply: > >>On Sun, Oct 10, 2004 at 04:40:48PM -0700, Reid Spencer wrote: >> >>>http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards >>> >>>is your answer. >> >>I think their "answer" is lame; we have already sacrificed portability >>because we are using enough of gmake-only functionality because we >>cannot depend on the system "make" being anything useful, yet gmake is >>portable, and hence, the "standard". > > > I agree completely. > > >>The thing about "distribute only what you list", well... maybe, but the >>way "WE" do distribution is (I believe) checkout, build, test, make >>clean, make dist. That way, you *know* that what you're distributing >>actually works. But I'm not the distro person, that's John. :)Typically, I do the following: Checkout LLVM with release tag. Make Distro. Unpackage distro. Build Distro. Test Distro. Yes, I'm paranoid. :)> > > Well, automake changes all that. Right now it takes John 1-2 weeks to do > a "distro". automake can produce a VALIDATED distribution automatically > with only CPU time involved. The "distcheck" target builds a > distribution candidate, produces a tar.gz of it, unpacks it, rebuilds > it, and if everything is okay, the tar.gz is good to go. This will find > ALL KINDS of subtle errors and a big part of getting the distribution > right is setting up the _SOURCES variables to list things correctly.FWIW, I don't believe that the build system for LLVM proper is the problem. I think the problems stem from the following: o) The llvm-gcc binary distributions take awhile due to the following complications: o After building it, I put the build into a cfrontend directory and add copyright files and fixheader scripts. o For systems in which I don't want to deal with header file licensing issues (i.e. Solaris and MacOS X), I remove all of the system headers that GCC fixed when I built it. o Building llvm-gcc and LLVM is sort of a chicken and egg problem. I have to build LLVM, then llvm-gcc, and then build llvm/runtime and install it into the llvm-gcc binary tree. And if something gets fixed in LLVM, it might change the libraries created by llvm/runtime, so keeping everything in sync is kind of a pain. o) Problems which don't affect day to day work typically don't get fixed until release time. Despite many people's efforts to fix bugs immediently when they show up in the nightly tester, problems slip through because our day to day priorities don't allow us to fix every problem. Part of that two weeks is one week worth of hurriedly fixing bugs that we've neglected (because for releases, we want everything that worked in the previous release to work in this current release). Chris has recommended that we schedule some "cleaning up" time more regularly to relieve this burden. o) We support 3 platforms in-house (one of which gets neglected), and each new platform that I can build increases the problems caused by the two things above. I believe the two best things that we can do to shorten releases is the following: 1. Re-arrange the LLVM and LLVM-GCC builds to build in one fell swoop. I checkout out, I type make, and it all builds. This requires moving parts of llvm/runtime into llvm-gcc, or making llvm-gcc an LLVM project, or some other approach. 2. Schedule some time at least a month before the release to start polishing LLVM and fix regressions that haven't already been tackled, per Chris's suggestion. I don't believe automake will make releases go any faster because it doesn't solve the 2 problems listed above. The LLVM core works pretty well; it's the interaction with llvm-gcc that is problematic. That said, I'm not against automake. I just want to point out what I think the release bottlenecks are. -- John T. -- ********************************************************************* * John T. Criswell Email: criswell at uiuc.edu * * Research Programmer * * University of Illinois at Urbana-Champaign * * * * "It's today!" said Piglet. "My favorite day," said Pooh. * *********************************************************************
John, The point I was trying to make (and obviously didn't) was that because automake can make the mechanics of building/testing/packaging a release so much easier (one command), it is possible for this to be automated regularly (e.g. nightly test). Consequently, the problems only seen when building a distribution would be available much sooner than the week before the release. Distribution problems would be detected like any other bug and reported from the nightly tester. One other benefit of its simplification is that developers can also easily type one command before going to bed and see what they get in the morning. This would also help us find those tricky distribution bugs faster. Each developer could generate the same results independently and (hopefully) hasten the bug fixing process. FWIW, I agree that the current situation with llvm-gcc is not ideal, but most of us just build llvm-gcc once and forget about it. The real solution here is to endow LLVM with its own C/C++ compiler and bootstap, but that's a longer strategy. Reid. On Mon, 2004-10-11 at 07:39, John Criswell wrote:> Reid Spencer wrote: > > On Sun, 2004-10-10, Misha Brukman asked "Why can't we use wildcards > > instead of listing all the sources" and then wrote in response to my > > reply: > > > >>On Sun, Oct 10, 2004 at 04:40:48PM -0700, Reid Spencer wrote: > >> > >>>http://www.gnu.org/software/automake/manual/html_mono/automake.html#wildcards > >>> > >>>is your answer. > >> > >>I think their "answer" is lame; we have already sacrificed portability > >>because we are using enough of gmake-only functionality because we > >>cannot depend on the system "make" being anything useful, yet gmake is > >>portable, and hence, the "standard". > > > > > > I agree completely. > > > > > >>The thing about "distribute only what you list", well... maybe, but the > >>way "WE" do distribution is (I believe) checkout, build, test, make > >>clean, make dist. That way, you *know* that what you're distributing > >>actually works. But I'm not the distro person, that's John. :) > > Typically, I do the following: > > Checkout LLVM with release tag. > Make Distro. > Unpackage distro. > Build Distro. > Test Distro. > > Yes, I'm paranoid. > :) > > > > > > > Well, automake changes all that. Right now it takes John 1-2 weeks to do > > a "distro". automake can produce a VALIDATED distribution automatically > > with only CPU time involved. The "distcheck" target builds a > > distribution candidate, produces a tar.gz of it, unpacks it, rebuilds > > it, and if everything is okay, the tar.gz is good to go. This will find > > ALL KINDS of subtle errors and a big part of getting the distribution > > right is setting up the _SOURCES variables to list things correctly. > > FWIW, I don't believe that the build system for LLVM proper is the > problem. I think the problems stem from the following: > > o) The llvm-gcc binary distributions take awhile due to the following > complications: > o After building it, I put the build into a cfrontend directory and add > copyright files and fixheader scripts. > o For systems in which I don't want to deal with header file licensing > issues (i.e. Solaris and MacOS X), I remove all of the system headers > that GCC fixed when I built it. > o Building llvm-gcc and LLVM is sort of a chicken and egg problem. I > have to build LLVM, then llvm-gcc, and then build llvm/runtime and > install it into the llvm-gcc binary tree. And if something gets fixed > in LLVM, it might change the libraries created by llvm/runtime, so > keeping everything in sync is kind of a pain. > > o) Problems which don't affect day to day work typically don't get fixed > until release time. Despite many people's efforts to fix bugs > immediently when they show up in the nightly tester, problems slip > through because our day to day priorities don't allow us to fix every > problem. > > Part of that two weeks is one week worth of hurriedly fixing bugs that > we've neglected (because for releases, we want everything that worked in > the previous release to work in this current release). > > Chris has recommended that we schedule some "cleaning up" time more > regularly to relieve this burden. > > o) We support 3 platforms in-house (one of which gets neglected), and > each new platform that I can build increases the problems caused by the > two things above. > > I believe the two best things that we can do to shorten releases is the > following: > > 1. Re-arrange the LLVM and LLVM-GCC builds to build in one fell swoop. > I checkout out, I type make, and it all builds. This requires moving > parts of llvm/runtime into llvm-gcc, or making llvm-gcc an LLVM project, > or some other approach. > > 2. Schedule some time at least a month before the release to start > polishing LLVM and fix regressions that haven't already been tackled, > per Chris's suggestion. > > I don't believe automake will make releases go any faster because it > doesn't solve the 2 problems listed above. The LLVM core works pretty > well; it's the interaction with llvm-gcc that is problematic. > > That said, I'm not against automake. I just want to point out what I > think the release bottlenecks are. > > -- John T.-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041011/5fb30213/attachment.sig>
On Mon, 11 Oct 2004, John Criswell wrote:> I believe the two best things that we can do to shorten releases is the > following: > > 1. Re-arrange the LLVM and LLVM-GCC builds to build in one fell swoop. > I checkout out, I type make, and it all builds. This requires moving > parts of llvm/runtime into llvm-gcc, or making llvm-gcc an LLVM project, > or some other approach.FWIW, this would be very valuable in its own right, in addition to making the release easier to manage. Ideally, I would like to make the LLVM core not depend or provide any C/C++ FE related stuff at all. -Chris -- http://llvm.org/ http://nondot.org/sabre/