Slashdot Mirror
SourceForge Announces Compile Farm
HeUnique sent us the NewsAlert press release regarding SourceForge's new compile farm. For the projects hosted there, it means that they will be able to do test compiles on both Linux and *BSD systems.
← Back to Stories (view on slashdot.org)
Sorry for forgetting this link:
http://bento.FreeBSD.org is the moniker for the actual port-building cluster. Satoshi's documented some very good ideas there, including trying each port under its own clean chroot to make sure dependencies are correct.
It seems you've already gotten the idea of putting multiple distros in chroots on the machine, so it could be trivially extended to have a tarball containing that environment that could be unpacked and chrooted to for testing :) That's how the building for 3.X-STABLE is done, on top of a 4.0-CURRENT base.
It might be really nice to have a ports-type tree to do this, with more simplistic Makefiles which have targets for configuring, compiling, installation, and cleaning. Full SourgeForge "tree" building could be done that way =)
--
Brian Fundakowski Feldman
It's a place where they do eieio . . .
:)
Accually we are working on getting some other platforms (sparc, alpha, ppc, etc..)
- U
This is VERY true.
:-)
:-)
When we had 'free software' it compiled on pretty much everything that smelt of Unix and often on things that didn't.
Now, much of the latest and greatest 'open source' software seems to think that cross platform means RPMS for Red Hat AND SuSE. It really annoys me. I see shit like "This was designed as a cross platform project, so it should work on Linux and *BSD".
Increasingly, the quality of applications can be linked to the number of supported platforms and the number of geeky libraries required. The more platforms and fewer libraries, the better.
My definition of cross platform does NOT include requirements such as:
1. The GNU version of tar
2. The GNU version of make
3. Any particular kind of C compiler beyond specifying ANSI compliance or other standards compliance
At work I have a very well looked after Sparc-solaris 2.7 box. Free software that doesn't build on it, and whose readmes only talk about Linux goes straight in the bin. Yes, I do email the authors so they can fix it. No I don't immediately sign up as the official Solaris porter for the project and fix it myself. Yes I do like to point out that if they'd written it in Perl* they wouldn't have these problems
The traditional argument has been that the developers don't have access to the wide range of platforms to test on. Cynics like me might point out that SHURELY wonderful amazing open source software will never suffer from such problems because it has 2.6 billion potential developers who have every known flavour of every hardware to test it on. Sure...
So, it would be nice to see a place with some HP-UX machines, some RS/6000 gear, and some Irix boxes so that people can actually write cross platform code. Or, to be more accurate, so that people would no longer have an excuse when they didn't write cross platform code.
*Substitute Java for Perl if you feel that way inclined
-----
This leads me to an interesting problem. I am developing a program. I am using FreeBSD as my development enviroment but my target environments are BSD/OS, OpenBSD, FreeBSD, SunOS, and possibly UnixWare. Obviously, anything else would be great on top of this. But how does one write code that will compile without problems across so many different architectures and platforms? Is autoconf the way to go? Is there a decent manual on autoconf? The standard documentation that comes with it is a bit lacking in how to make it work with a new project. Ideas?
This means that anyone can execute arbitrary code on their compilefarm servers by including it in the build scripts. They need to make sure they have really good local security.
Another problem is that some software packages assume that "make install" will always be executed by root and include things like "install -o root" which will fail for non-root users. This is the most common reason for source RPMs which cannot be built by a non-root user.
----
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Ol' Sourceforge had a compiler farm..
E- I/O I/O.
And on this farm they had a cluster..
E- I/O I/O.
With a make make here,
And a make make there..
Make make make make everywhere!
Ol' Sourceforge had a compiler farm..
E- I/O I/O.
---
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
This is a good start, but it really needs other Unices than the free ones to be included. Have you tried compiling a C program under SunOS 4 recently? Or HP-UX 9? These are where the real compatibility issues are revealed, IME.
(Of course, compiling under Windows/Mac/BeOS/etc. too would be even better, for programs which are intended to be used there.)
11.0010010000111111011010101000100010000101101000
It's a service by Compaq which you'll find right here http://testdrive.compaq.com/
BTW, it wasn't posted a few years back, just 1-1.5 year ago...
Enjoy
I didn't have a look at SF.net yet to read about this, but I'm already wondering if it will be a i386-only farm or Sparc, Alpha, PPC, etc. will be available.
Many bugs in the Debian Bugtracking system are "fail to compile under foo arch" bugs, so it would be very cool to be able to test the code under various archs to avoid this. That would make SourceForge a unique environment to squash these types of problems, as many programmers can be aware their code does not compile on Sparc but they can't do anything about it as they don't have access to a Sparc machine.
About being able to execute binaries, and X and all... that sounds a bit more difficult here, imagine what hardware you need to allow that number of X sessions?
It's about time an organized effort was made to keep source code portable across the free OSs.
/proc) code, and won't build anywhere but on Linux (maybe even specific distros?)
This is why C was invented in the first place, but too many people forget it.
Many programs already compile on multiple OSs, and kudos to their respective authors for writing good code. Other programs only require minor changes, which is where autoconf makes it easy. Then there's the occasional code that assumes Linux only (kernel or
</RANT>
Then there's the whole "Linux" software phenomenon. It's sad when people don't realize that the programs they use in Linux aren't "Linux" programs, they're Unix programs. I don't just mean grep, etc. I mean programs like XMMS, GNOME, KDE, etc. This stuff compiles, unmodified, on the *BSDs as well. Even some authors call their software "Linux" software when it's portable *as is*. This is misleading, both towards the Media, who pick up on it, but to new free Unix users as well, who might be deciding between Linux and a BSD. This new offering from SourceForge will not only provide a place for authors to test their code, it will help educate people as to the true nature of Open Source as well.
`./configure && make install` shall set you free.
<RANT>
--
My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
---
SourceForge Programmer Type - http://sourceforge.net
---
Drew Streib, dtype.org
I see a lot of questions regarding what is available on the Compile Farm, and a lot of great ideas as well. I'd like to dispel a couple of myths and offer some insight as to where this is going as well.
First, this is not a web-only service. We do like to provide web interfaces to as much as possible, but we do realize that for some things, program compliation and testing included, nothing can substitute for shell access.
A lot of people are asking about other hardware architectures and OS's. For now, the Compile Farm is i386 based, and contains several Linux distributions and FreeBSD. This does not mean that we have ruled out other possibilities. This is just another step in what we hope can be an expanding feature set for Open Source developers on SourceForge.
There is a lot of setup involved in something like this Compile Farm, not the least of which is having thousands of skilled Open Source developers with shell accounts on a set of boxes. We're attempting to keep things as secure as possible while also offering enough features to make this thing useful. One reason for the limited number of distributions/architectures/OS's now is the limitation of variables in a very complex system. Hopefully, we can work out the kinks in this system soon so that it can become a valuable resource to developers who might not otherwise have the capability of getting their hands on so many different machines.
We're also working on giving users the advantages ot having a cluster of machines available. Uriah Welcome worked very hard to provide parallel make capability to projects, and this is being tested now. (Parallel makes will allow you to take advantage of multiple dual-processor machines simultaneously in your compiles.)
Please be patient as we test this new system. We're definately open to criticism, but please also be constructive with it so that we can continue to improve these services. Thanks to all of the SourceForge users who have contributed patches, criticism, and helpful suggestions. Every day my confidence in the Open Source model increases...
---
SourceForge Programmer Type - http://sourceforge.net
---
Drew Streib, dtype.org