0

I'm working on a project with two other developers that's built on FireBreath. So far, I've been able to get things working perfectly on my machine, but we need to coordinate our development via Mercurial. So I pushed my files to the repository and thought all was well.

Unfortunately, that doesn't work.

The various .vcproj files that make up the solution all contain hard-coded references to my local file system. This works fine for me, because I'm not moving the project around. But when you try to build the solution on another machine with a different file structure (different drive letter, different folder location, etc.) everything breaks.

I used FireBreath's standard project generation script (Python) and then the Visual Studio CMake script (prep2008.cmd) to generate the solution files. What can I do to tweak things so that other developers can use the same code base?

taxilian
  • 14,229
  • 4
  • 34
  • 73
EAMann
  • 4,128
  • 2
  • 29
  • 48

4 Answers4

5

If your developers are not using the same build/make/project files, this could quickly become a maintenance nightmare. So you should definitively all use the same .vcproj files. (An exception to this would be if the project files were generated from some other files. In that case treat those other files in the way described above.)

there's two ways to deal with the problem of differing setups on different machines. One is to make all paths relative to the project's path. The other is to use environment variables to refer to files/tools/libraries/whatever. IME it's best to use relative paths for everything that can be checked out with the project, and use environment variables for the rest. Add a script that checks for the existence of all necessary environment variable, pointing out the meaning of any missing ones, and run this as a build prerequisite, so whoever tries to get a new build machine up and running gets hints at what to do.

sbi
  • 219,715
  • 46
  • 258
  • 445
  • I like the idea of the self-documenting build. – anton.burger Nov 20 '10 at 20:11
  • @sbi: you are completely ignoring the fact that those .vcproj files are generated with FireBreath. – Doc Brown Nov 21 '10 at 06:48
  • @Doc: Oh. I don't know FireBreath. What does it do? – sbi Nov 21 '10 at 09:34
  • @sbi: AFAIK it generates the .vcproj files. So changing them directly or manually may be not the best way to solve the problem. Look into the FireBreath FAQ, as I wrote in my post. – Doc Brown Nov 21 '10 at 13:42
  • 1
    @all: Yes, FireBreath generates the `.vcproj` files dynamically, and it turns out that these do *not* need to be kept under source control. The `projects` folder contains all our source, the `build` folder (containing the `.vcproj`s) just contains project and solution files that relate the project source with FireBreath. Use SCM on the project, *not* on Firebreath ... then run the CMake commands on each machine to rebuild the `.vcproj`s with references to the local system. Works beautifully! – EAMann Nov 21 '10 at 16:15
  • @Doc & @EAMann: I see. I added a sentence regarding generated project files to my answer. Hope this helps. – sbi Nov 21 '10 at 16:17
  • Exactly; you should never save the build/ directory or reuse the .vcproj files. see http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/ – taxilian Dec 02 '10 at 07:20
3

To make sure that everyone caught the updated comments from sbi's answer, let me give you the "definitive" answer from the FireBreath devs.

Your build directory is disposable; you should never share .vcproj files. Instead, you should regenerate your build/ directory any time you change the project and on each new computer, just like any project that uses CMake.

For more information, see http://colonelpanic.net/2010/11/firebreath-tips-working-with-source-control/

For reference, I am the primary author of FireBreath and I wrote the article.

taxilian
  • 14,229
  • 4
  • 34
  • 73
2

I'm not familiar with FireBreath, but you need to make the references relative, and then recreate that relative structure on every machine. That is, if your project sits in "c:\myprojects\thisproject" and has an additional include directory "c:\mydir\mylib\include", then the latter path needs to be replaced with "....\mydir\mylib\include".

Michael Repucci
  • 1,633
  • 2
  • 19
  • 35
0

EDIT: I rewrote my anyswer to make it clearer. When I got you correctly, your problem is that FireBreath generates those .vcproj files with absolute paths in it, and you want to use this .vcproj files on a different developer machine.

I see 3 options:

  1. Live with it. That means, make sure, every team member has the same file structure / view to the file system, tools installed in the same place.

  2. Ask the authors of FireBreath to change their .vcproj generator to allow relative paths, use of environment variables etc.

  3. If 1 or 2 does not work, write a program or script for changing the absolute path to relatives in those .vcproj files. Run this script whenever you have to regenerate your FireBreath project.

What you should not do due to the FireBreath FAQ: don't change the .vcproj manually, those changes will be lost next time the project is regenerated.

EDIT: seems that "option 4." turned out to be the best solution: generating those .vcproj files for each developer individually. Hope my suggestions were helpful, either.

Doc Brown
  • 19,739
  • 7
  • 52
  • 88
  • And then what do you do when you need to switch one developer to another project? Re-install his whole machine? – sbi Nov 20 '10 at 21:46
  • Well, I have never been a situation where file structures of different projects were completely incompatible. If my suggestion is applicable depends a lot in what kind of organization you are working. – Doc Brown Nov 21 '10 at 06:52