Good techniques to use Makefiles in VisualStudio?

Question

I know the ideal way to build projects is without requiring IDE based project files, since it theoretically causes all sort of trouble with automation and what not. But I\'v

Answer 1

We use a NAnt script, which at the compile step calls MSBuild. Using NAnt allows us to perform both pre- and post-build tasks, such as setting version numbers to match source control revision numbers, collating code coverage information, assembling and zipping deployment sources. But still, at the heart of it, it's MSBuild that's actually doing the compiling.

You can integrate a NAnt build as a custom tool into the IDE, so that it can be used both on a build or continuous integration server and by the developers in the same way.

Answer 2

Ideally perhaps, in practice no.

Makefiles would be my preference as the build master, however, the developers spend all their time inside the visual studio IDE and when they make a change, it's to the vcproj file, not the makefile. So if I'm doing the global builds with makefiles, it's too easily put out of synch with the project/solution files in play by 8 or 10 others.

The only way I can stay in step with the whole team is to run devenv.exe on the solution files directly in my build process scripts.

There are very few makefiles in my builds, where there are they are in the pre-build or custom build sections or a separate utility project.

Answer 3

How about this code?

public TRunner CleanOutput()
{
    ScriptExecutionEnvironment.LogTaskStarted("Cleaning solution outputs");

    solution.ForEachProject(
        delegate (VSProjectInfo projectInfo)
            {             
                string projectOutputPath = GetProjectOutputPath(projectInfo.ProjectName);

                if (projectOutputPath == null)
                    return;

                projectOutputPath = Path.Combine(projectInfo.ProjectDirectoryPath, projectOutputPath);

                DeleteDirectory(projectOutputPath, false);

                string projectObjPath = String.Format(
                    CultureInfo.InvariantCulture,
                    @"{0}\obj\{1}",
                    projectInfo.ProjectName,
                    buildConfiguration);
                projectObjPath = Path.Combine(productRootDir, projectObjPath);
                DeleteDirectory(projectObjPath, false);
            });

    ScriptExecutionEnvironment.LogTaskFinished();
    return ReturnThisTRunner();
}

public TRunner CompileSolution()
{
    ScriptExecutionEnvironment.LogTaskStarted ("Compiling the solution");

    ProgramRunner
        .AddArgument(MakePathFromRootDir(productId) + ".sln")
        .AddArgument("/p:Configuration={0}", buildConfiguration)
        .AddArgument("/p:Platform=Any CPU")
        .AddArgument("/consoleloggerparameters:NoSummary")
        .Run(@"C:\Windows\Microsoft.NET\Framework\v3.5\msbuild.exe");

    ScriptExecutionEnvironment.LogTaskFinished ();
    return ReturnThisTRunner ();
}

You can find the rest of it here: http://code.google.com/p/projectpilot/source/browse/trunk/Flubu/Builds/BuildRunner.cs

Answer 4

We have a program that parses the vcproj files and generates makefile fragments from that. (These include the list of files and the #defines, and there is some limited support for custom build steps.) These fragments are then included by a master makefile which does the usual GNU make stuff.

(This is all for one of the systems we target; its tools have no native support for Visual Studio.)

This didn't require a huge amount of work. A day to set it up, then maybe a day or two in total to beat out some problems that weren't obvious immediately. And it works fairly well: the compiler settings are controlled by the master makefile (no more fiddling with those tiny text boxes), and yet anybody can add new files and defines to the build in the usual way.

That said, the combinatorical problems inherent to Visual Studio's treatment of build configurations remain.

Answer 5

We use the devenv.exe (same exe that launches the IDE) to build our projects from the build scripts (or the command line). When specifying the /Build option the IDE is not displayed and everything is written back to the console (or the log file if you specify the /Out option)

See http://msdn.microsoft.com/en-us/library/xee0c8y7(VS.80).aspx for more information

Example:

devenv.exe [solution-file-name] /Build [project-name] /Rebuild "Release|Win32" /Out solution.log

where "Release|Win32" is the configuration as defined in the solution and solution.log is the file that gets the compiler output (which is quite handy when you need to figure out what went wrong in the compile)

Answer 6

Personally, I use Rake to call msbuild on my solution or project. For regular development I use the IDE and all the benefits that provides.

Rake is set up so that I can just compile, compile and run tests or compile run tests and create deployable artifacts.

Once you have a build script it is really easy to start doing things like setting up continuous integration and using it to automate deployment.

You can also use most build tools from within the IDE if you follow these steps to set it up.