Adding SFML vs2008 projects to my solution...

[MrDoomMaster]

Hi,

Currently I have my game in a vs2008 Project. I externally link to the SFML repository, and it would be nice to be able to include the SFML vs2008 project to my own solution. By doing so, when I get updates my solution will automatically build the SFML libraries when I try to build my game. My game project, of course, would put a dependency on the SFML project in my solution settings.

However, I cannot do this because of the way your project is setup. Right now to add SFML to my solution, I'll be adding around 6 projects and I'll also have to setup your SFML project dependencies again, which can change at any time. It's not practical to add SFML to my solution at this time.

Is there any way I can add SFML to my solution easily? Could you possibly change the way the SFML project is structured, so that it uses only 1 project? I don't think adding solutions to solutions is possible.

Any help is greatly appreciated. Thank you.

[Aszarsha]

I only use Window and Graphics (and System, of course) packages, and I don't want to include Network nor Audio package to my project.

I don't mind adding a new project that would contain everything, but the current machinery should stay as is.

[MrDoomMaster]

I don't mind adding a new project that would contain everything, but the current machinery should stay as is.

That would be great, thank you.

::EDIT::
I just thought of a great idea. I can build the SFML solution from the command line as a pre-build event in my project I can invoke devenv.exe from the command line

[Laurent]

Do you really need to build SFML each time you build your project ? Can't you just rebuild it after major changes, or when you really need a new feature that has been added ?

By the way, did you already try to add the 6 SFML projects to your solution ? I think the dependencies are handled externally, so that it can remain even when I update the project files. Just give it a try.

[MrDoomMaster]

Do you really need to build SFML each time you build your project ? Can't you just rebuild it after major changes, or when you really need a new feature that has been added ?

I don't build it every time I build my project. What happens is this: If I do an SVN update and I get code changes for SFML, then the next time I build my project it will automatically compile only the SFML source files that have changed, thus updating the libraries. This would happen before my actual project is compiled, as I would make my project depend on your SFML projects. This ensures my project is built last.

If the source is not changed, then the SFML projects will be skipped and take up no processing time as they do not need to be recompiled. Visual Studio takes care of this for you.

By the way, did you already try to add the 6 SFML projects to your solution ? I think the dependencies are handled externally, so that it can remain even when I update the project files. Just give it a try.

I don't know what you mean by "externally". Whatever the case, the solution files keep track of project dependencies. So SFML.sln is the file that knows about what projects depend on what projects. Since I cannot add a solution to my solution, I cannot carry-over the dependency information.

If you were to make the SFML solution just 1 project instead of 6, you could manage dependencies at the project-level (instead of at the solution-level). This would provide programmers the ability to add your SFML project to their own solutions without having to do a lot of manual upkeep.

However, on the other hand you may not be able to make it one project. It already looks like a complex setup. I'll leave the eligibility decision for such a change up to you.

[Laurent]

If the source is not changed, then the SFML projects will be skipped and take up no processing time as they do not need to be recompiled. Visual Studio takes care of this for you.

I know. What I mean is, do you really need to have the latest version of SFML, recompile it each time there's a new revision ?
Sometimes I revert some changes, or do more modifications to a validated feature. I think you will just waste your time always trying to stick to the latest source ; as I said :

Can't you just rebuild it after major changes, or when you really need a new feature that has been added ?

If you were to make the SFML solution just 1 project instead of 6, you could manage dependencies at the project-level (instead of at the solution-level). This would provide programmers the ability to add your SFML project to their own solutions without having to do a lot of manual upkeep.

I'm definitively not going to do that. Gathering every module in one library is exactly what I want to avoid

[MrDoomMaster]

Sometimes I revert some changes, or do more modifications to a validated feature. I think you will just waste your time always trying to stick to the latest source

That's what branches are designed for in SVN. Yes, the trunk is the development branch and is *potentially* unstable, but by no means should it be unstable on purpose. When you're testing a feature or doing experimentation, you do this on a branch. When you're comfortable with the feature-set and stability, you merge it to the trunk. This is how SVN was designed.

In any case, I'm not trying to change the way you work. Your library is great, and free, so I am no where near the point of complaining or being dissatisfied. Given the unstable condition of the trunk (I had assumed it was somewhat stable), I'll remove the external link and use a release build.

Also, another reason why I link to your subversion development branch is to save space on my own SVN server. I do the same with the boost library (which is, needless to say, substantially larger in terms of bytes than SFML).

I'm definitively not going to do that. Gathering every module in one library is exactly what I want to avoid

I completely agree. In fact, now that I look back on it, I can't believe I even suggested it. Bad me, bad! I suppose I was just desperate.

In any case, building the SFML solution via a pre-build event in my project worked out beautifully. However, there are no "custom clean events" in Visual Studio 9 (nor any earlier version), so I can't really clean the project when I clean my solution. However that is negligible.

Thanks for your feedback!

[Laurent]

I didn't mean to say that the trunk is unstable. The changes I was talking about are most of the time minor ones, but sometimes they modify the public interface and your code needs to be updated each time it happens.

I'm currently not using branches at all (I really should -- same goes for tags), but when I do a major modification I don't commit anything until the code has been completed and tested. So I wouldn't say it is unstable, it's sometimes just not the final public interface.

And thanks for your feedback too

[MrDoomMaster]

I don't commit anything until the code has been completed and tested.

Well, the way I see it, there are only 2 reasons why I would make a branch to backup changes that require a week or so to complete:
1) For the purposes of backup & ability to revert. Keeping changes checked into the server is always better than keeping it modified on your working copy. If your machine's HDD fails, at least you can sleep at night knowing your code has been safely checked into your branch, even if it doesn't compile! It doesn't matter what the code looks like or how it functions, that's why it's in a branch!
2) Multiple developers. If I have a partner working on the same branch and helping me with a feature, it's pretty much a requirement to make sure your changes are checked into the branch so your partner can access those changes.

I personally don't like keeping things modified for too long on my working copy just because I'm paranoid about my hard drive failing at any time. If a feature I'm working on takes more than a day or two, I create a temporary branch for backup purposes.

I'm probably stating the obvious here, however I'm not trying to educate you. I'm just expressing how I use SVN for my personal needs. I would hate for you, too, to lose your work if your hard drive fails

Thanks for your prompt feedback. Again, you have a great library. Keep up the most excellent work you're doing!