views:

150

answers:

5

Hi,

I am looking for documentation on how to commonly do the technical part of publishing the source of first open source projects, in particular with library-intensive stuff in C/C++, Java, Python.

To give an example, if I built a C++ project with an IDE like Netbeans and various libraries like Xerces-C and Boost, I would like to find out about these questions:

  • which are the most common tools to organize the build process for such a process outside of my own environment, and more importantly

  • how do I learn them in the way that it is 'generally being done' ? I use many open source projects and can certainly read the build code (makefiles and config options and so on), but that doesn't tell me how to get there, what are the important details and what is generally expected.

  • is there for specific languages (like the ones mentioned) something like a 'coding style' guidance on deployment ? Are there open source projects that have guidelines on that ?

  • when deploying source code (rather than packages with apt/port/etc, where you can resolve dependencies), what is the typical way to deploy library dependencies ?

I know that I can read all the manpages and all the documentation, but I would like to read about the 'conventions' and how they are implemented and expected rather than all the possible technical options.

I found this one on another stackoverflow post, it's nice, but not very specific: http://producingoss.com/en/producingoss.html

Thanks for any input !

+2  A: 

You could start with http://llvm.org/docs/DeveloperPolicy.html and http://llvm.org/docs/CodingStandards.html. The LLVM project is a very well organized opensource project.

Richard Pennington
Thank you, but that's more about coding standards rather than source deployment/build standards, I'm looking for documentation on how to get away from '.. well it runs on my machine ..'.
Homer J. Simpson
I'm not sure if this helps, but this is what I have for my project: http://ellcc.org/installation.html. The instructions are a bit complex because I use stuff from a variety of sources.
Richard Pennington
+2  A: 

As you seem to be writing Linux apps, you might want to take a look at the GNU autotools such as autoconf. There is actually a good book on them, and they will handle most dependency problems for you.

anon
Nice links, thanks.
Homer J. Simpson
+2  A: 

Let's look at one of open-source features. If you want to learn how it's deployed, download a couple of similar open-source projects and learn from them. So, find one that's done like yours and study its sources.

Why should it help? The thing is that open-source projects have to be able to build on users' machines easily. Otherwise noone will be able to contribute to them. Therefore all necessary information about how they should be deployed is usually included in INSTALL or README files witihn the sources you downloaded. They usually consist of several simple steps. For the same purpose, checking availability and versions of prerequisites is automated (in configure scripts), and sometimes such scripts even aid in installing them.

What is generally expected is something like

# Download sources (this line is read from your website)
wget http://myapp.org/myapp-source-2.15.tgz
tar -xzf myapp-source-2.15.tgz
cd myapp-2.15
less INSTALL
# read INSTALL file, where instructions about installing prerequisites are
./configure --help
# Read help, learn about possible options
./configure --prefix=/install/here --without-sound
make
make install

Nowadays some applications use cmake instead of autotools (the stufff with configure script).

I doubt that Linux projects actually requires NetBeans as a build system--that would be an overkill. But this IDE seems to generate makefiles, so ship them. You may also commit IDE-specific porject files into repository, for convenience, but it shouldn't be the primary way of building your soft.

There're some more things users expect to find in your package:

  • Licensing information (usually in LICENSE file and at the beginning of every source file as well)
  • Link to project homepage (where to report bugs)
  • Coding guidelines (as a text flie)
  • Information for maintainers (how to bump version, how to add module, etc)
Pavel Shved
You're right about Netbeans, that what I actually said, I want it to become independent from my own private environment.Probably you're right and simply reading a lot of sources and documentation will help, but I was hoping that there is something like a standard way to do it and a description of how it is being done. The configure/make/makeinstall process is of course such a thing, and I was wondering if someone had probably written a book or site on the whole process of packaging and publishing source towards a general public (because 'normal' books are about shipping products).
Homer J. Simpson
For transforming from NetBeans to generic makefiles, you might want to write a special "maintainer's" script (and maybe publish it as well). About organizing code, there's not much to write about, aside from writing about using specific tools (like autotools or cmake). Just check any source code for what should be there (I'll edit my answer for some ideas).
Pavel Shved
+1  A: 

I recommend this: http://producingoss.com/

This book explains most of the commonly used procedures, as well as lots of social things, f.e. how to cope with contributors.

liori
A: 

What is you are looking for is build-system++

If you develop for POSIX (linux) platforms or you work only with MingW under Win32 that I would suggest to learn how to work with autotools -- autoconf/automake/libtool and friends.

It gives you, source-code packaging, configuration, testing, installation. They are firendly for distribution packagers (deb/rpm).

They have quite steep learning curve, but they are very powerful tools for these tasks.

However, if you want to support MSVC compiler, I would suggest to take a look on CMake, IMHO it is less powerful and requires much more writing, but you would need this for Windows with all dllexport/import issues (or, in less gentle words -- crap).

This is what you are looking for.

Artyom