Home/ Questions/Q 529333
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T09:04:51+00:00

I am looking for documentation on how to commonly do the technical part of

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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)
    • 0