Clever Geek Handbook

What's a good way to create a lot of small tools in Visual Studio?

Let's say you have source code that comes from the unix world. This source consists of several files that will create the library and many small .c files (like about 20) that are compiled into command line tools, each with its own function main()

that will use the library.

On unixy systems, you can easily use a makefile, but the most naive conversion to the Windows / Visual Studio world involves creating a separate project for each tool, which, although it works, is a lot of work to set up and sync up and is harder to navigate both at the file level system and at the project / solution level. I thought about using different configurations in which all but one .c file are excluded from the build, but that would make it impossible to build all the tools.

Is there a good way to create all the tools from one "thing" (project, msbuild file, etc.)?

I'm really not interested in using cygwin gcc / mingw or NAnt. I would like to stick to the standard Windows toolchain as much as possible.

+2


source to share


4 answers


So I've been looking at this for a while and all solutions leave a lot to be desired.

You can...

  • Create many small projects by hand.

  • Use MSBuild and consider its steep learning curve.

  • Use a build tool that doesn't integrate well with Visual Studio, such as GNU make.



You can't even create a project template like you can with .NET projects! Well, you can do the wizard if you want to wade through the docs by doing this, I suppose. Personally, I decided to go with the "many small projects" solution and just handle it. Turns out it might be less awful than I thought, although it still sucks. Here's what I did in Visual Studio 2008:

  • Build your first Win32 command line tool project, get all your settings for all platforms, and make sure it works under all circumstances. This will be your "template", so you don't want to edit it after you've made 20 copies.

  • (optional) I have set my paths in visual studio project files so that everything is generated in the project directory, after which I have a copy of the post build step only of the dll / exe / pdb files I need $ (SolutionDir) $ (OutDir). This way you can go into one directory to test all your tools and / or complete them for a binary distribution. VS2008 seems insane and outputs patches all over the place, with Win32 and x64 output being placed by default. Spending a few minutes to ensure all platforms are compatible will pay off later.

  • Clean up your template. Get rid of any custom preferences and compiler output files.

  • Copy and paste your project as many times as you need. One project per instrument.

  • Rename each copied project folder and project file to the new tool name. Open the project file in a text editor such as Notepad ++. If you have a simple 1 file project, you will need to change the project name in two places at the beginning of the file and the source code file name at the end of the file. You don't need to touch the configuration content in the middle.

  • You will also need to change the GUID for the project. Open open guidgen.exe (in SDK bin directory) and use the last switch setting. Copy and paste the new GUID into each project file at the top. If you have dependencies, there will be one or more GUIDs at the bottom of the file next to the source code. DO NOT modify them as they are GUIDs from dependencies and must match!

  • Go to Visual Studio, open the main solution and add your project projects.

  • Go to the config manager and make sure everything is correct for all supported platforms, then check your build.

It's not pretty, but it works, and it's very important for setup time to be able to control your builds from the GUI. Hopefully VS2010 is better about this, but I'm not overly hopeful. It seems like MS is putting more emphasis on the .NET community than the C / C ++ community these days.

+1


source


You don't need to use visual studio to compile your code. You can create your own batch file or Powershell script that just calls the compiler on your source, just like a makefile.



+1


source


If you have a makefile, you can use the makefile project in Visual Studio (which is in the wrong name - it just lets you specify custom build / debug commands) and use it to invoke GNU make.

You will need to modify the makefile to use the VC ++ command line tools instead of cc or gcc or whatever it uses, but often these are given by macros at the top of the makefile.

If the makefile uses other special Unix commands (such as rm), you may need to make changes or create bath files to map commands to Windows equivalents. Another option is to install any necessary tools from GNUWin32 for it to work.

If the build is very complex or includes configure scripts, then you have a more complex task. You can generate a makefile from a configure script using MSYS / MinGW and then modify it as above to work with VC ++.

Makefile projects will not be so tightly integrated into Visual Studio. All build management is up to you and the makefile.

0


source


If you are actually using Visual Studio, I would suggest creating a project for each tool and adding those projects in one solution. It's easy to create a complete solution from Visual Studio, and MSBuild also knows how to create .sln files.

msbuild myslnfile.sln

or even:

msbuild

... will build your solution.

-1


source






More articles:


All Articles