Vistual Studio project files

[Bas Vodde]

Hiya all,

I got a question related to Visual Studio project files.

Now, we have 2 major builds: 1) Autotools (using configure) and 2) cmake (using cmake :P).

CMake can also generate Visual Studio project files (correct?). In fact, I believe this is one of the reasons why CMake was created.

Question #1: Shall we remove the Visual Studio project files from the repository and only use the CMake one?

Question #2: Should we create the project files in the build, so that they *would* be in the released packages? Or let users do it themselves?

Thanks!

Bas

[Andy Neebel]

Personally I'm not particularly fond of CMake, but I haven't really used it much.  I tried to build KDE4 a while ago, and it was a pain, so I gave up and never tried again.  That said, I do like Visual Studio a lot and prefer to work in it over any other environment I've used.

 

What I do remember is that the project files end up being a bit odd at times, especially with logic in them to try and regenerate the project files if the something in the CMake files has changed.  I have learned a lot about Visual Studio and MSBuild over the past couple years, and feel like I have better control over the build process when working with the project files directly compared to relying on auto-generated files.  I sometimes write customizations for tools at work to easily enable them to be added to our projects, and find this to be a very powerful mechanism.  However, this ties a little bit into how are you supposed to add CppUTest (or any framework for that matter) or other tools to your project.  I have had that debate with a few people, and it never really seems to be resolved.  Some people prefer to include the header files and either library or source (please no) in their project directly, while other people like to have things installed on the computer and not include outside tools in the source control system.  I tend to be in the second, but there is an issue with making sure you're using the right version then - especially on a long running project.

 

That said, I understand the desire to have a single build system in place in terms of easier maintenance.  I don't know how many people here actually use Visual Studio with CppUTest, given the cross-platform nature of it, and what I think is some focus on it being usable on embedded targets, I suspect it is more commonly used inside Eclipse or some other IDE's that aren't so focused on one platform.  I will say that if you're going to rely on CMake to generate files, that I don't think it make sense to include them in source control.  There may be value in generating them to include in the release zip files, but that raises the question of which version to generate, or have packages for each version, etc...  Similar question is should there be some binary/header only releases instead of always relying on the user to build the library file?

 

I have had a few ideas of things I'd like to do to improve the Visual Studio environment, but some of those are just personal preferences, and then I got distracted with another project.  That and I found out that one of my ideas doesn't actually work in 2012 Express like I thought it would (turns out no plugins really is NO plugins).  If that environment is now going to be auto-generated from CMake, then a lot of it doesn't really matter anymore.  There is the question though of what about the people that don't have CMake and either can't install it (corporate policies maybe?) or don't want to install it?

 

I think I maybe raised more questions than I answered, and while I have some ideas, I'm really doubting my ability to actually do them (time mainly), so I don't know if I'll really end up using whatever happens anyways.

 

Andy

[Bas Vodde]

Hi Andy,

Excellent, the type of answers that I was looking for.

This answers at least the second question, which is, if we remove the project files, then we'll need to at least include them in the release. I assume most peopel who use VS will not use cmake, so we wouldn't want to create that dependency. Good.

First question is tougher though. We defintively want to support and probably increase our support for VS. We've got a couple of problems right now:

- We'll need a project file for each VS version, which will be hard to maintain (especially as James and me work on Macs).
- If the project files aren't maintained will (like now). Are they then more harmful than beneficial?
- The files kinda clutter the root, I'm trying to clean that up a bit so that everything is nice and clean. I like it nice and clean (we'll also need to remove the autotools files from there soon)
- Will the cmake-ed generated files be such a turn-off that people won't use them?

Any VS people would want to try to CMakefile generated projects?

Bas

> --
> You received this message because you are subscribed to the Google Groups "cpputest" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cpputest+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[mart...@gmail.com]

Guess I'm biased, being that I created the cmake files, but I think we should remove the vs files. The reasons being, less build systems to maintain. Less clutter in the root as well as automatic support for new vs releases.

Cmake already supports a wide variety of build systems, so with cmake we get support for visual studio, nmake, eclipse, code::blocks and many more. Since we obviously can't add all that to the root, they should all be handled by cmake. This also makes the building of these a lot easier, as we don't have to maintain a system neither Bas nor James use.

When it comes to part two, stuff gets harder. Not sure how easy we could move the generated vs files to other environments. Might work, but have never tried. My suggestion is: either create an executable installer for the release on windows or, if possible, add the generated vs files to the project. Cmake does generate a couple though, guess we will end up with six for each vs version. So will have to have a cleaner way than just putting it in the root. Maybe something like root/vs/vs20(10/11/12). If we think an installer is sufficient, I can help create one using cmake, which has support for this.

Personally i think that the fewer build systems we have in the root of the project the better. Having projects for all different vs releases just makes the first you see of the project a mess, while what you are interested in is "where's the code".

- Martin

[Bas Vodde]

Hi Martin,

Thanks!

Just curious… do you use VS yourself?

An installer is interesting. I was thinking of generating the project files in the travis-ci build and storing them in the zip. But probably not in the root if it generates 6 of them!

Bas

[mart...@gmail.com]

Primarily I'm a Linux guy, so no. But I have used it some, and are still using it occasionally to make sure what I make works on windows. Using Jenkins for ci on my personal projects, and have been to lazy to create a windows worker.

I can look some into the installer. It will create installer for windows, Mac and (at least I think) Linux. Guess it would be beneficial anyways, for people that don't want to care where stuff is put, and only wants cpputest installed locally.

- Martin