I've inherited some C99 code that I'm planing on reusing in a C++-centric solution. Unfortunately, even Microsoft's latest compiler has virtually no support for non-trivial C99 features.
The code in question has been tested to death and I'd rather not go through the trouble of rewriting it in C++. This means that in order for me to reuse the code verbatim I'll have to rely on a conforming 3rd-party compiler.
After looking around, it appears that the nicest way for me to integrate this code is by adding a "Makefile Project" to my solution. Only one problem. It seems like it is now my responsibility to keep the "Build Command Line" property synchronized with the files that I add to the project through Visual Studio.
At first glance, I couldn't find a way to get a list of files in my project through the usual Visual Studio $()-style macros. I could always write a shell script that would enumerate *.c files in my source tree and pass their paths to the 3rd-party compiler. However, I kind of expected that Visual Studio would do at least that part of the work for me since it already has this information in the relevant *.vc[x]proj file.
It is very unlikely that I'll need to add any new source files to this project, but still, manual synchronization (i.e., without a script) of this sort seems rather fragile to me.
What are my options besides writing a helper script?
From Hans Passant:
"Makefile project" means what it says,
there needs to be another 'agent'
that's responsible for the
dependencies. Like a make file. Rule
files can help you select another
build tool but that's kinda broken
right now in VS2010. Leverage the
original tool that built this C99
code, run it from the makefile
project.
Related
I have a build process (let's call it the "engine") that has been using a command line call to Visual Studio's devenv.exe to build a project. I have known for some time that VS is just building with MSBuild, so I finally got around to updating the engine to use MSBuild directly. However, I'm finding a strange anomaly with MSBuild.
For the sake of discussion, there's projects A, B, C, and D. Project A is the main project I'm building, a web app, that depends (through project references) on the other 3 projects. When built manually in VS, A\bin is populated with assemblies. When built in the engine with devenv.exe A\bin is again populated with the expected binaries. When built in the engine use MSBuild, A\bin contains nothing. However, B\Release\bin, C\Release\bin and D\Release\bin contain their binaries as they did using the former 2 build methods.
This happens with just a single project as well. The problem doesn't appear to be related to dependent projects.
I have attempted to explicitly set the MSBuild OutDir property, but it doesn't appear to have any affect.
I have run builds with diagnostic output on and can't see anything obvious (granted, there is a LOT there so it's possible I have yet to find something significant).
I've also been trying to figure out how to see the command line call to MSBuild that VS is making when run from devenv.exe but I can't seem to find it.
I have looked at several other SO posts (here and here) but they aren't the same problem.
Anyone have an idea of what this could be or where else I could look for an answer or more diagnostic information?
EDIT 1: The arguments pattern used for the call to MSBuild looks like this:
/nologo /target:Compile /property:Configuration=%%BUILDCONFIG%% /maxcpucount
/property:OutDir=%%OUTDIR%%\bin\ /verbosity:diag /detailedsummary "%%PROJPATH%%"
The lower half of that shows my attempt to force the output directory as well as the enhanced output to show more details of the process. Build engine code replaces with "%%TOKEN%%" items with the appropriate replacement values for the project being built.
EDIT 2: After more research and looking into suggested provided, I've decided to abandon the effort to use msbuild instead of devenv. It seems there is a lot more going on under the hood of devenv in preparation its own call to msbuild and I could likely break something else going on if I don't fully understand the entrance in msbuild. I did try to see if the call to msbuild from devenv is logged, but it doesn't seem to be. I've considered building a dummy msbuild app to just dump the command going into it and temporarily swap out the actual msbuild to generate this diagnostic information, but that's more effort than it's worth at this point. The performance gain isn't so great that it's worth pursuing further for now.
I would look at the Output path on the build tab of your project properties. There are more than few differences when using MSBuild and when using Visual Studio (Even from the command line). It could be you have A configured differently than B,C,D and synching A to the rest will make it work. Also, if you plan to build the projects individually, not as a solution make sure you don't use Solution Level macros that won't be available to the project file on it own.
You are supposed to set OutputPath instead of OutputDir.
Since you already used /verbosity:diag, why not redirect the output to a text file and carefully analyze where csc.exe (or another compiler in use) stores the binaries? That's quite simple and informative for you to learn how MSBuild works under the hood.
In most .NET project I can use folder to organise the code files. In C++, I can't, but filters end up playing the same role. However, in F# with Visual Studio 2010, I can't. Every code file is shown directly in the project dir. Why is this feature not available?
And what is the optimal strategy for organizing a project with a lot of files?
Actually, you can add folders to F# projects but it's not supported directly through Visual Studio (you have to edit the project file yourself): http://fsprojectextender.codeplex.com/ (edit: old link was broken, updated to F# Project Extender home page which has links to the original blog posts which were moved) (which I found in this answer).
I do this myself, but it is cumbersome and you end up avoiding it until keeping sanity really demands it. I think the feature simply slipped, or perhaps there wasn't as much a culture for folder organization with the F# designers in the first place. You can see in the F# source code that they favor huge source files with no directories, with separate projects as an organization boundary.
I imagine the F# project template could be modified to support this, and it is certainly something I'd like to see happen. At the same time the linear compilation order F# enforces causes your code to be somewhat self-organized, and so folder grouping plays a less significant role.
Manually editing the .fsproj file as described in Stephen's answer is one option (and I used it when I wanted to organize one larger project).
However, you have to be a bit careful and I think you cannot add new files to the folders (creating a file by hand and then adding an existing file works). However, if you like to keep things organized (like I do), then it should work for you.
Additionally, there is also a tool called F# Project Extender that should make things a bit easier for you . I have not tried it yet, but it looks like it supports adding folders (and perhaps other useful things). See for example this blog post by the project author.
We have a few hundred visual studio project files that I need to assemble into a solution for building. We currently have a custom ruby script, that uses rake, to do this. But is fragile, and only allows a few visual studio macros ( $(TargetDir),$(TargetName), etc...) through, and failing on the rest. Plus the grammar of Ruby rubs me like Perl: The wrong way.
So my question is, given a directory is there a tool that will recursively find all all the .vcxproj and .csproj files and generate a solution file with dependencies? When I say 'with dependencies' it means that some projects need to be built before others. I found some other posts here on stack overflow that pointed to a tool that generates solution files: but it doesn't generate dependencies. Therefore without dependencies any solution creation tool is completely useless. Does anyone know of something that will do this?
If not a solution file, does anyone know of something that will just emit a dependency list?
P.S.
And before anyone asks: creating a solution file manually is completely out of the question. We simply have way too many project files.
So my question is, given a directory
is there a tool that will recursively
find all all the .vcxproj and .csproj
files and generate a solution file
with dependencies?
No.
What you're asking for is very reasonable; your approach to the problem is quite rational. Unfortunately, the tools haven't kept up with you. (We had the same problem.)
You're going to have to script that yourself, or otherwise customize tools. That's what we did. Successful approaches I've seen include:
Generate the *.vcproj/*.sln from
"reference project definitions",
using tools like CMake, QMake, Scons, or
Gyp. Our main system currently sits
on Scons, with our custom Python
code to navigate these dependencies,
generate solutions based on projects
(spidering dependencies). By
default, we generate a "complete"
solution for each project (including
all required supporting projects),
plus a "Master All Projects"
solution. It works very well. But,
it was custom work that took effort,
and we extended Scons somewhat to
describe our projects (but we simply
rely on the Scons generation of
*.sln and *.vcproj).
Write a custom tool to "find" these dependencies by
parsing all the *.vcproj files in
your workspace. This is work, but can be done. Those files can be "tricky" to navigate, but you might be fine with a "good enough" solution that uses the GUIDs as hash keys to generate those dependencies.
I totally agree with you: This type of stuff (project dependencies) is prohibitively difficult to maintain manually when you move beyond "simple" (e.g., many dozens of projects, yes, we also have hundreds).
Sorry. MSVS is a pretty good IDE (intended for iterative development), and a terrible build configuration management system, and not designed to do what we're talking about.
Because I care about your sanity and Your Everlasting Soul, please Please PLEASE do not attempt to write your custom solution in MSBuild.
On a side note, having hundreds of VS projects is a bad idea, it will kill VS performances, see the two white-books:
Partitioning code base through .NET assemblies and Visual Studio projects (8 pages)
Defining .NET Components with Namespaces (7 pages)
I know I will miss so much of Visual Studio but I am getting really sick of it crashing all the time and being slow, PLUS it is always changing things in my repository that I don't want to change, so I want to just edit with Notepad++. However, now I will have to load up VS just to build things. Is there a way I can build from command line and make a script for it and what not? Will it show the compile errors?
Please don't try to troubleshoot VS for me, I am just asking what is in the question and the rest was just given for context and so nobody was like 'Y U NO RIKE VIZAL STUDIA?'.
build: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe "PATH TO YOUR SOLUTION FILE"
help: C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe /help
What you need is directly calling csc.exe, the C# compiler (which is called by the build system of Visual Studio, anyways). If you ever worked with GCC, it is quite similar except that options are passed Windows-style with / signs instead of -- and there are no object files or additional linking. The MSDN library has documentation: http://msdn.microsoft.com/en-us/library/78f4aasd.aspx.
Generally, you'd need something like:
csc /target:exe /out:Something.exe *.cs
plus any /reference's you would add in Visual Studio.
If your project is large, it may be uncomfortable to maintain a .bat file to do the compilation, so a build tool like NAnt may be needed, which is quite similar to the Ant used for Java.
This is of course if you want to eliminate Visual Studio entirely. Otherwise, Snowbear's solution of invoking MSBuild.exe will be just as fine.
I would like to use Visual Studio 2008 to the greatest extent possible while effectively compiling/linking/building/etc code as if all these build processes were being done by the tools provided with MASM 6.11. The exact version of MASM does not matter, so long as it's within the 6.x range, as that is what my college is using to teach 16-bit assembly.
I have done some research on the subject and have come to the conclusion that there are several options:
Reconfigure VS to call the MASM 6.11 executables with the same flags, etc as MASM 6.11 would natively do.
Create intermediary batch file(s) to be called by VS to then invoke the proper commands for MASM's linker, etc.
Reconfigure VS's built-in build tools/rules (assembler, linker, etc) to provide an environment identical to the one used by MASM 6.11.
Option (2) was brought up when I realized that the options available in VS's "External Tools" interface may be insufficient to correctly invoke MASM's build tools, thus a batch file to interpret VS's strict method of passing arguments might be helpful, as a lot of my learning about how to get this working involved my manually calling ML.exe, LINK.exe, etc from the command prompt.
Below are several links that may prove useful in answering my question. Please keep in mind that I have read them all and none are the actual solution. I can only hope my specifying MASM 6.11 doesn't prevent anyone from contributing a perhaps more generalized answer.
Similar method used to Option (2), but users on the thread are not contactable:
http://www.codeguru.com/forum/archive/index.php/t-284051.html
(also, I have my doubts about the necessity of an intermediary batch file)
Out of date explanation to my question:
http://www.cs.fiu.edu/~downeyt/cop3402/masmaul.html
Probably the closest thing I've come to a definitive solution, but refers to a suite of tools from something besides MASM, also uses a batch file:
http://www.kipirvine.com/asm/gettingStarted/index.htm#16-bit
I apologize if my terminology for the tools used in each step of the code -> exe process is off, but since I'm trying to reproduce the entirety of steps in between completion of writing the code and generating an executable, I don't think it matters much.
There is a MASM rules file located at (32-bit system remove (x86)):
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCProjectDefaults\masm.rules
Copy that file to your project directory, and add it to the Custom Build Rules for your project. Then "Modify Rule File...", select the MASM build rule and "Modify Build Rule...".
Add a property:
User property type: String
Default value: *.inc
Description: Add additional MASM file dependencies.
Display name: Additional Dependencies
Is read only: False
Name: AdditionalDependencies
Property page name: General
Switch: [value]
Set the Additional Dependencies value to [AdditionalDependencies]. The build should now automatically detect changes to *.inc, and you can edit the properties for an individual asm file to specify others.
You can create a makefile project. In Visual Studio, under File / New / Project, choose Visual C++ / Makefile project.
This allows you to run an arbitrary command to build your project. It doesn't have to be C/C++. It doesn't even have to be a traditional NMake makefile. I've used it to compile a driver using a batch file, and using a NAnt script.
It should be fairly easy to get it to run the MASM 6.x toolchain.
I would suggest to define Custom Build rules depending on file extension.
(Visual Studio 2008, at least in Professinal Edition, can generate .rules files, which can be distributed). There you can define custom build tools for asm files. By using this approach, you should be able to leave the linker step as is.
Way back, we used MASM32 link text as IDE to help students learn assembly. You could check their batchfiles what they do to assemble and link.
instead of batch files, why not use the a custom build step defined on the file?
If you are going to use Visual Studio, couldn't you give them a skeleton project in C/C++ with the entry point for a console app calling a function that has en empty inline assembly block, and let them fill their results in it?
Why don't you use Irvine's guide? Irvine's library is nice and if you want, you can ignore it and work with Windows procs directly. I've searching for a guide like this, Irvine's was the best solution.