I'm currently working on a small library as a hobby project. I am the only one who actively codes for it, but a few of my friends have expressed interest in participating in the future.

When using the library for my own purposes, I usually just add the appropriate source files to my project using an IDE. (E.g., dragging a .h and .cpp file into Xcode.) As the library grows in size and complexity, however, I've been trying to move towards a more professional approach to organization.

I've considered setting up some sort of makefile that future participants can use to compile the library into a "monolithic" library file. This might be beneficial to me as well, since I code on multiple computers. Would such a venture be worth the effort?

Note: I tried looking at the Boost library to see how they do things, but it's pretty difficult to navigate without any previous experience and I had trouble making sense of the structure.

  • Doesn't Xcode allow you to create a project that is a library, rather than an executable?
    – Dima
    Commented May 6, 2011 at 20:39
  • I've not used XCode, but in my experience the whole point of using an IDE is so that you don't have to write your own makefiles and that kind of tedious stuff. You just create a project, add files through the IDE and then it works out how to compile them. You would share your project with your friends; not just the files.
    – user23157
    Commented May 6, 2011 at 20:41
  • @Dima @B Tyler Yep, but my other computer is a PC and the library in general is cross-platform. I could just put project files for every IDE in the repository, but then I'd have to keep them all updated and synchronized. Using IDE project files might work in a more formal work environment where everything is standardized, but since this is open-source I can't rely on everyone having the same setup.
    – Maxpm
    Commented May 6, 2011 at 20:42
  • 1
    keeping two sets of project files synchronized is definitely easier than manually adding the source files to every new project. For automating the synchronization take a look at cmake.
    – Dima
    Commented May 6, 2011 at 20:45

6 Answers 6



Your IDE of choice is likely to change within the lifespan of the code, especially if you leave the code, and return to it in 5-10 years time.

It's also good when you're sharing code to make it easy for others to use their tool of choice, rather than unintentionally impose your environment on them.

It's worth investigating automake/autoconf as these help make code portable on UNIX-like systems (including OSX, which is essentially BSD with proprietary libraries / filesystem layout), and possibly Windows.

Make sure you think about how (or if) you want to license the code before sharing with your friends - you can't impose a license after distributing it, which may be relevant if you ever commercialise the project, or want to stop others commercialising it.

  • +1: Autoconf is pretty good, but I'm not so sure I'd recommend automake; when it goes wrong, it's very difficult to work around. Commented May 7, 2011 at 9:05

Yes, especially if you considering such option - do it.

Automatic deployment methods always greatly increases overall experience for you and others. Just keep in mind that Makefile works in UNIX and UNIX-like systems only (http://en.wikipedia.org/wiki/Unix-like). So windows user will not be able to use it.

Sure in my case since were using buildout and Makefile, it [Makefile] acts only as some sort of smart Alias for long ones or bunch of commands, so users under windows just stick to buildout and are entering longer commands in cmd. But back to the question - automation in this case still worth the time for us since majority deployment servers and coworkers are using Linux and each time we deploy time is cut in half and this for the ones who created the system and know it.

So my suggestion would be, look what methods would shorten deployment/configuration time as much as possible, and how fast you could setup it. In this case Make file i guess would be great option. Try to make something that you would like to get your self. I personally would like to get one-command-install and good documentation. I doubt that others would want something else.

  • 1
    Actually, GNU make is available on Windows. gnuwin32.sourceforge.net/packages/make.htm Commented May 7, 2011 at 0:44
  • And with a different syntax but also a "Make" there is Microsoft nmake. It ships with VS and with the SDK, if I recall correctly.
    – Vitor Py
    Commented May 7, 2011 at 2:22
  • Wallacoloo, i didin'tknew it :) thanks. Vitor Braga, Different syntax means different code. So You will have to write programs instead of one and in your system only one will work. Thats rather a bad option. Well in my personal opinion just.
    – JackLeo
    Commented May 7, 2011 at 6:25
  • I've used Gnu make on windows for many years. Its just fine. And if you write a makefile to gnu make then it can (with great care) be used on unix and windows platforms. Commented May 7, 2011 at 10:01

Yes, build automation tools are extremely important for any complex project.

The project files your IDE uses may be used by other build automation tools, which works well for many situations. These days Visual Studio projects can be compiled by a standalone tool MSBuild, which is good for many build automation tasks.


I don't know if it supports XCode since I doesn't use it but for, at least for me, the holy grail is a "meta build system", ie. an application that build Makefiles, VS Projects, for wherever platform I'm using or porting my project. After that you can build the project using the native way.

So you keep just a project for this meta build system, and it generate native makefiles (or ...) for the platform you're running.

This is how Qt projects are usually built.

I used to use heavily qmake, from Nokia (Trolltech). I think CMake is the more well build system that works in the way I described.

I saw autoconf being suggested in another answer, well, I don't believe someone has real world experience with it and with substitutes and likes it. It's messy, at least for me. Stay clear of it.


Using libraries is more complete solution. I mean that everything is inside the library and all you have to do is #include the header files you need for the declarations. The only thing you have to remember is set the paths for the header files and library in your project makefile as well as include a linker command to link your program with your library. This approach will keep your program makefiles a lot cleaner since there will be fewer files. At the end the linker will put in your final executable only the code required. If on the other hand you include the files manually you may link a lot more code than the one required. It may seem a little complicated to have two projects (library and program) but I believe it pays back in the end.

  • That's what I'm trying to do. The makefile would be for compiling the library, which users would use along with header files.
    – Maxpm
    Commented May 6, 2011 at 20:56

Since others have already answered about the build automation part, I just want to add, that if your library grows and you want to share the code, you should have a look at version control like git or svn as well.

  • 1
    Already done. I have a Google Code project.
    – Maxpm
    Commented May 6, 2011 at 23:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.