8

Suppose you are working on some project that supports several configurations (linux and windows builds, shared/static linking, with some feature or without, etc). To build all these configurations you need different versions of 3rd party components (built with gcc or msvc, shared/static, with some specified preprocessor definitions, etc). So eventually you end up with a problem of managing all these configurations not only for your project, but for all the libraries your project is using.

Is there a general solution/approach/software to facilitate managing several different configurations of a single project?

Criteria:

  • Ease of setup, i.e. how much time one would need to spend to build your project from scratch?
  • Ease of management, i.e. is it hard to add new dependency or remove an existing one?
  • Error proof, i.e. how often developers will break the build by changing dependencies?

So far I've tried several approaches.

  1. Store prebuilt packages for every configuration under VCS.

    Pros: Ease of setup while project is small (update working copy and you are good to go). Ease of management (build library once for every required configuration). Error proof (VCS client notifies you about changes in your working copy).

    Cons: Doesn't work well for distributed VCS (GIT, Mercurial, etc.). Repository grows rapidly and eventually a simple "clone" operation will be intolerable. You also end up downloading a lot of stuff which you don't really need (i.e. windows libraries if you are working on linux). And if you are implementing library, then users of your library will inherit all these problems by integrating it in their project.

  2. Store library sources instead of prebuilt packages.

    Pros: Ease of setup.

    Cons: It is extremely painful to add a new library. You need to provide build scripts and source patches for every configuration. But that is only the tip of the iceberg. Your dependencies have their own dependencies, which have their own, so on and so forth ... You have a good chance to end up with something like a Gentoo distribution :)

  3. Store an archive or just a folder with prebuilt packages somewhere on the external server.

    Pros: Solves the problem... kind of.

    Cons: Not so easy to setup (you have to copy the archive manually). Not so easy to manage (you have to add each library to a server by hand). No history of changes. Not error proof, because it is easy to forget to put something on the server, or to remove something useful.

    Slightly improved approach: you can use a centralized VCS (for example, SVN) to store all 3rd party libraries, it will be easier to work with. But still you either don't have a centralized history of changes if you use it as a simple file storage, or you get a huge repository with lots of unnecessary libraries if you use it as a sub-repository.

durron597
  • 31,968
  • 17
  • 99
  • 158
DikobrAz
  • 3,557
  • 4
  • 35
  • 53
  • 1
    Most 3rd party libraries I use come with all their dependencies when you download their source, so they just build. But as you've mentioned that makes them much larger than they probably need to be. I personally write a script to clone/checkout/download those libraries to a nearby folder, and then I build them as part of the build process of my own source. Most annoying is when those libraries come with a build system that forces you to start an IDE and press a button. – enobayram Dec 03 '12 at 14:00
  • @enobayram What kind of build system forces you to "start an IDE and press a button"? How do you handle these? I mean, do you press the button manually or use some automatic solution? – kol Dec 03 '12 at 14:32
  • @kol some libraries distribute a "project file" for a particular IDE, such as codelite, instead of a proper cross-platform build system like cmake. As far as I know (because I've searched and couldn't find anything), there's no way of telling codelite from the command line to build a project, so you need to start it and press "build". – enobayram Dec 03 '12 at 14:36
  • 1
    possible duplicate of [Can (Should) I put 3rd party libraries in version control?](http://stackoverflow.com/questions/1710027/can-should-i-put-3rd-party-libraries-in-version-control) – durron597 Sep 16 '15 at 18:56

1 Answers1

2

When you faced with such type of problems, you have to learn and start using Configuration Management tools (besides usual technics of your SCM of choice). CM is process, and using some of Configuration Management Tools is part of this process.

Currently we have greate choice of different CM-tools, in which you can select best-fit or just preferred. From my POV, Chef is "Best Choice for Everybody", you mileage may vary

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110