Guest post by InfoWorld’s Peter Wayner takes a look at 13 open source development projects making waves in the enterprise. From Git to Hadoop to build management tools, “even in the deepest corners of proprietary stacks, open source tools can be found, often dominating. The reason is clear: Open source licenses are designed to allow users to revise, fix, and extend their code. The barber or cop may not be familiar enough with code to contribute, but programmers sure know how to fiddle with their tools. The result is a fertile ecology of ideas and source code, fed by the enthusiasm of application developers who know how to ‘scratch an itch’.”
Yeah, I’d much rather use GCC, on mac, and windows, as I use it on Linux. Togheter with a good crossplatform framework. Just a quick recompile away, and no fiddling with and learning other software packages, downloading, installing etc.
Technically you are correct. Although building GCC on any platform is a nightmare, using it is supported by many other tools like Qt Creator using Qt and Code::Blocks under wxWidgets. Nonetheless, I hope Clang takes center stage in ways that GCC cannot.
GCC has no JIT compiler capabilities, no IDE integration support, and is not as well documented as Clang is. Likewise the LLVM mailing list is much friendlier, I’ve heard, than what GCC’s is.
I’m surprised you say this.
I’ve been building GCC-based cross compilers on both Windows (Cygwin) and Linux without any single issue to date. Everything has always worked as expected by boringly following the instructions. Among all source packages I’ve ever put my hands on, GCC has been the easiest to play with by far.
Agreed, aside from the fact that GCC DLLs are incompatible with Visual Studio (e.g. VC++) produced DLLs. If they resolved that they GCC could replace VC++ very easily. But then, MS would probably introduce another incompatibility.
They are not compatible? I thought DLLs providing just a plain C interface – where this can be incompatible?
There’s something different in how GCC/G++ layouts out the DLL versus VC++ such that a VC++ application cannot load a GCC/G++ built DLL and vice versa. Not sure what exactly it is, just know it exists.
There are probably ways to get around it, but you’d have to work at it to do it.
They are not technically incompatible… Its just that GCC has its own ABI and _that_ is different from the MSVC ABI (this is not at all uncommon – ABIs are often quite different across different vendors compilers).
You can work around it if you have the .def file produced by GCC (assuming it was produced under cygwin). With the .def file, you can generate a compatible import library (.lib) file in MSVC and use that to interface with the dll.
There are of course other issues you can run in to besides this one, there are quite a few commonly used features in GCC that are not strictly standards compliant…
Edited 2011-04-19 17:52 UTC
Exactly.
Many Linux users never realize this, because they only use gcc.
Actually there is no standard ABI in any system.
Most Unixes default to the same ABI as the system compiler.
In Windows, following the MS-DOS and CP/M roots there is no concept of standard system ABI. As such each vendor has its own offerings for object and library files.
In the case of DLLs you need to make use of an import library, if you want to reference it at link time. The only vendor neutral way of doing it is via .def files.
Actually this is not Windows specific, there are other systems with import libraries. Aix is one of them.
And no mention of Valgrind?! It is one of them most awesome and powerful tools ever. I was recently chasing a memory bug and was crying tears that Valgrind is not available on Windows. I was already using a memory debugging library that was doing everything that can be done by a library. But it didn’t show anything. I really needed a tool that can break right when the code uses the freed pointer – the library would only catch problems later or not at all.
There are no comparable free tools on Windows. The Purify trial is a joke – it won’t show you details of about the problems that it finds. I heard of Intel Parallel Inspector but didn’t try it – maybe it’s trial is at least useful. Other tools require you to instrument your code manually – at the binary (Bounds Checker) or source (Insure++) level. And they have no trial versions.
So big thumbs up for Valgrind!
I’ve found that doing initial development and debug on linux first gets aboout 95% of the problems. Moving over to windows I find I can deal with just release builds for everything and not have to deal with library hell on windows.
I would like to add that the barber or cop can contract someone to add a feature that he needs, and then share the improvement with all the other users.
Call me a stick-in-the mud, but I don’t like Git.
I am kind of that way all around, as I cannot say I’m a huge fan of the new “NoSQL” options either. I think the idea is sound and a good direction to go, but my favorite ‘key/value’ style database by far is a classic: BerkeleyDB (http://en.wikipedia.org/wiki/Berkeley_DB). It has been under active development for over 20y and is rock solid.
Edited 2011-04-19 20:52 UTC
Funny enough, it was berkeley db that caused me to switch to git. SVN uses berkeley. Had a few too many issues with suddenly corrupt repos.
I’ll actually agree with you on that, but I prefer to use SVN with filesystem storage instead. I’ve set up quite a few repositories over time, and never had a problem in that configuration.
My understanding on the SVN/BDB problems was that it wasn’t BerkeleyDB itself, but how SVN was driving it.
Edited 2011-04-20 16:21 UTC
Not sure about the validity of the analysis in the summary.
I think a big part of popularity of open tools is still the “sharecropper” effect:
http://www.tbray.org/ongoing/When/200x/2003/07/12/WebsThePlace
Once you have an open tool, you “own your future” in a way someone using proprietary tools doesn’t.
“To use an analogy, Git is like democracy, while CVS represents the old feudal world.”
This analogy, metaphor, whatever, is very weird to my eyes.
If the guy has been able to merge projects under categories like “Preprocessors”, “Content management systems” and “Build management tools”, he could as well have used “Distributed Version Control Systems” while using Git as the most prominent member of that clique. There’s more to DVCSes than “just” Git. Mercurial and Bazaar for instance aren’t negligible. Just saying.