Hi All,
It has been entirely too long since the last release, and we have plenty of goodies for a very solid release. Do people find releases useful, or should we just continue to run out of CVS? Does anyone have any thoughts?
-Chris
As I'm not particularly active with LLVM right now, it doesn't make any difference to me, personally. However, I am a strong advocate for "release early, release often". We had previously agreed to releases 4 times per year. This will be the 3rd and final one this year. Many users of LLVM only work from release to release so it is unfair to them to let them stray very far from the CVS "head" simply for lack of releases.
I think the improvements made to the code base over the last few months have been VERY significant, especially on the backend. I think the current work on the new backend architecture should find a logical stopping point and then the release put out after sufficient testing.
My $0.02 worth.
Reid.
Chris Lattner wrote:
Hi,
We definately need regular releases because that is what distribution package
managers focus on. We need to be able to say "use LLVM 1.6 or later". Some
linux distros as well as Fink (OSX) currently 'have LLVM 1.5 and I assume
they will upgrade when a new release is available.
Plus I think it is a good for any development team to have these regular
deadlines. From my own projects I know there are a million things that are
not as much fun as hacking on new stuff and therefor only get done when
releases are eminent. Most of the time my mind forces these things to the
background until they can no longer be ignored.
regards,
Eric
I think a release is due. All the work on the backends since last
release is worth a release in and of itself. Also, for those who use
this in classes, having a release before the start of spring semester or
winter quarter would be nice.
For users who use cvs, having releases of the cfe is still probably very
handy.
Frequently releasing software can be a good thing. Especially when it
gets to a point where you have a stable CVS version and many new
features/bug fixes.
-bw
The automated tests seems not run periodically. Some builds are even
broken (http://llvm.cs.uiuc.edu/testresults/X86-niobe/), and some
failed (http://llvm.cs.uiuc.edu/testresults/SparcV9/).
Will there be another automated test be scheduled before the next release?
I agree with all the reasons others have cited for continuing to have regular releases: it's a catalyst for many things including getting users to update their code, distribution mangers to update distros, getting "nearly-done" pieces wrapped up, and lurking problems identified and fixed. In addition, it's a good excuse to spam a few lists with the announcement.
--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/
The automated tests seems not run periodically. Some builds are even
broken (http://llvm.cs.uiuc.edu/testresults/X86-niobe/), and some
failed (http://llvm.cs.uiuc.edu/testresults/SparcV9/).
For the build thats broken,the machine (Niobe) is probably dead. Its been having problems for awhile.
As for the Sparc backend.. it should be running nightly tests regularly. I'll see if I can at least get it up and running again. Do not expect any maintenance to be done on it because it will eventually be migrated to the new backend framework.
-Tanya
Spamming lists is probably the best reason to keep releases going. It's a
great way to find new users 
By the way, are any distributions currently
carrying LLVM? I couldn't find it in the Debian repositories.
Spamming lists is probably the best reason to keep releases going. It's a
great way to find new users
carrying LLVM? I couldn't find it in the Debian repositories.
Debian Sid (unstable) and Slink (testing) both have LLVM 1.4 - I'm not
sure if there's a specific reason they haven't moved to 1.5 (no bugs
have been reported for this).
David
Hello Chris,
It has been entirely too long since the last release, and we have
plenty of goodies for a very solid release. Do people find releases
useful, or should we just continue to run out of CVS? Does anyone
have any thoughts?
Yeah, I think so Also, it would be really nice if an official
cygwin build (the binary) was published too. I spent quite a bit of
time screwing with it a few months ago, and it was quite a bastard to
get going...
IMHO, it would be the easiest way to get some windows user playing
with llvm
Best regards,
Oleg.
Also, it would be really nice if an official
cygwin build (the binary) was published too. I spent quite a bit of
time screwing with it a few months ago, and it was quite a bastard to
get going...
I had quite a time with it too, could only get the debug version to build as there seemed to be an internal problem with ld.
I would very interested in how you got it running and what GCC tool versions you used ?
IMHO, it would be the easiest way to get some windows user playing
with llvm
Yes, but it is still limited.
Aaron
As I'm not particularly active with LLVM right now, it doesn't make any difference to me, personally. However, I am a strong advocate for "release early, release often". We had previously agreed to releases 4 times per year. This will be the 3rd and final one this year. Many users of LLVM only work from release to release so it is unfair to them to let them stray very far from the CVS "head" simply for lack of releases.
Makes sense. Somehow I expected this response from everyone
I think the improvements made to the code base over the last few months have been VERY significant, especially on the backend. I think the current work on the new backend architecture should find a logical stopping point and then the release put out after sufficient testing.
Absolutely.
How does this tentative plan sound: we have two more weeks of development, then start the release processing part on about Oct 31 (spooky!).
If have some plans for things that I will do to wrap up some features in the code generator. It would be great if the cygwin people can figure out what needs to be done to make cygwin work as well as possible for the release (and when the actual release happens, making a binary cygwin distro would be great!). If someone wants to help start whipping documentation (updating them as needed) and release notes (finding the bugs fixed and major features in the release) into shape, it would be a great help for me, otherwise I'll dive in next week.
-Chris
>As I'm not particularly active with LLVM right now, it doesn't make
>any difference to me, personally. However, I am a strong advocate
>for "release early, release often". We had previously agreed to
>releases 4 times per year. This will be the 3rd and final one this
>year. Many users of LLVM only work from release to release so it is
>unfair to them to let them stray very far from the CVS "head" simply
>for lack of releases.Makes sense. Somehow I expected this response from everyone
Well, I already read a few people echo my sentiments, but since you
expect this from _everyone_, let me second what Reid and Andrew Lenharth
have said.
How does this tentative plan sound: we have two more weeks of
development, then start the release processing part on about Oct 31
(spooky!).
In that case, it needs a cool "release name".
Suggestions welcome!
-Chris
In that case, it needs a cool "release name".
Suggestions welcome!
Names of flowers are numerous but not exactly cool. I do not think any other software project has used flower names.
Aaron
Hello Aaron,
Also, it would be really nice if an official cygwin build (the
binary) was published too. I spent quite a bit of time screwing
with it a few months ago, and it was quite a bastard to get
going...I had quite a time with it too, could only get the debug version to
build as there seemed to be an internal problem with ld.I would very interested in how you got it running and what GCC tool
versions you used ?
OK, I've just tried building the current CVS/HEAD on cygwin using
gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125):
- llvm/make tools-only worked ok
- llvm-gcc/make all failed with the following message (2nd try):
make[2]: Leaving directory `/home/oleg.smolsky/llvm-gcc-build/gcc'
make[1]: Leaving directory `/home/oleg.smolsky/llvm-gcc-build/gcc'
Checking multilib configuration...
multilib.out is unchanged
Configuring in i686-pc-cygwin/libstdc++-v3
configure: loading cache ../config.cache
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-cygwin-gcc... /home/oleg.smolsky/llvm-gcc-build/gcc/xgcc -
B/home/oleg.smolsky/llvm-gcc-build/gcc/ -B/pacific/llvm-gcc/i686-pc-cygwin/bin/
-B/pacific/llvm-gcc/i686-pc-cygwin/lib/ -isystem /pacific/llvm-gcc/i686-pc-cygwi
n/include -isystem /pacific/llvm-gcc/i686-pc-cygwin/sys-include
checking for C compiler default output... conftest.exe
checking whether the C compiler works... configure: error: cannot run C compiled
programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make: *** [configure-target-libstdc++-v3] Error 1
Best regards,
Oleg.
Oleg,
- llvm/make tools-only worked ok
Good.
- llvm-gcc/make all failed with the following message (2nd try):
make[2]: Leaving directory `/home/oleg.smolsky/llvm-gcc-build/gcc'
make[1]: Leaving directory `/home/oleg.smolsky/llvm-gcc-build/gcc'
Checking multilib configuration...
multilib.out is unchanged
Configuring in i686-pc-cygwin/libstdc++-v3
configure: loading cache ../config.cache
checking build system type... i686-pc-cygwin
checking host system type... i686-pc-cygwin
checking target system type... i686-pc-cygwin
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for i686-pc-cygwin-gcc... /home/oleg.smolsky/llvm-gcc-build/gcc/xgcc -
B/home/oleg.smolsky/llvm-gcc-build/gcc/ -B/pacific/llvm-gcc/i686-pc-cygwin/bin/
-B/pacific/llvm-gcc/i686-pc-cygwin/lib/ -isystem /pacific/llvm-gcc/i686-pc-cygwi
n/include -isystem /pacific/llvm-gcc/i686-pc-cygwin/sys-include
checking for C compiler default output... conftest.exe
checking whether the C compiler works... configure: error: cannot run C compiled
programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make: *** [configure-target-libstdc++-v3] Error 1
I am not sure but it looks like a problem with your Cygwin instillation ?
Try a 'make configure' or 'make reconfigure'.
Here's a link to the instructions I developed for building LLVM on Cygwin :-
http://angray.members.beeb.net/llvm/MakingLLVM.html
As far as I know it should hopefully still be correct for the debug build. It failed on the release build though due to a bug in ld, which hopefully will be fixed with time.
Aaron
Well, the subject matter for names ought to pertain to the subject matter of the software. Since LLVM is a "Low Level" Virtual Machine, how about we use the names of subterranean ores: granite, quartz, marble, etc.
Agan, not exactly cool, but a little better (IMO) than flowers
Reid.
Aaron Gray wrote:
Hello Aaron,
I am not sure but it looks like a problem with your Cygwin
instillation ? Try a 'make configure' or 'make reconfigure'.
Hmmm, I was able to build llvm/tools-only.... As for "make configure" -
that didn't help.
Here's a link to the instructions I developed for building LLVM on
Cygwin :-
http://angray.members.beeb.net/llvm/MakingLLVM.html
Yes, this is a nice, simple to follow digest of the "Bootstrapping the
LLVM C/C++ frontend" document. I've got my own notes, that are
identical to it, except for the paths So, yes, that's what I've
been doing.
And yeah, I was able to build a version of LLVM at some state... A few
months ago, I think. Debug only, IIRC.....
Best regards,
Oleg.