We have a C++ project that uses a custom object-relational-mapping system, in which tables are defined by .tbl files. These are then run through a code-generator that creates, for each, a .h and a .cpp file.
I'm trying to get a custom build rule working for this, in Visual Studio 2008 and 2010.
This is what I have, so far:
<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
Name="z_dbbld"
Version="8.00"
>
<Rules>
<CustomBuildRule
Name="z_dbbld"
DisplayName="z_dbbld"
CommandLine="$(SolutionDir)\tools\z_dbbld $(InputName)"
Outputs="$(InputName).cpp"
FileExtensions="*.tbl"
ExecutionDescription="z_dbbld $(InputName)"
>
<Properties>
</Properties>
</CustomBuildRule>
</Rules>
</VisualStudioToolFile>
The problem is the dependencies. When I run a build on a clean checkout, where none of the files exist, I get "Cannot open include file" errors, for .h files that are generated by this rule.
I've tried changing Outputs to "$(InputName).h", and I still get the errors.
Now the thing is that these files are created, when the code generator runs. If I compile again, I don't have the errors, because all of the files were created in the first pass. But it makes doing a clean, automated, build from fresh checkout not work.
Any ideas?
I think you need to specify the Output files in the main part of the build (looking at the very last sentence of http://msdn.microsoft.com/en-us/library/hefydhhy.aspx). Probably the easiest way to do that is to add a reference to the files when they exist and then delete them and see if the codegen step runs like it should.
The answer given by sblom is correct, but it does not explain the reason.
For each build rule (custom or native) the VS build system needs to know the complete list of inputs and outputs so that it can decide what part of the project needs to be built.
Your build rule declares the generated .cpp file as an output, so VS knows about it and will automatically build this file for you. Since you omitted the header file, VS does not know about it, so any source files that include this header will not know where to get it from and fail to build. A work around to get the build to work in this situation is to add the directory where this .h file is located to your include path, and then #includes of this file will work. You are basically enabling VS to know about this file in a different way.
Conversely, if you change your build rule to declare the header file as output, then source files that include it will know where to get this file from, but now VS does not know about your .cpp file so it won't build it. A work around for this case is to explicitly add the generated .cpp file to your project as a source file. Like in the above case, you are using a trick to get the build system to recognize the generated file.
But while the workarounds above will get you going they are not the best solution, since they just compensate for VS not knowing about a file. The best way to address this problem is to declare both the .cpp and the .h files as outputs in your rule, separating them with a semi-colon. This will enable VS to apply the correct behavior to both files.
Related
When I build solution in Visual Studio (2022), it generates an EXE (or DLL if I chose a class library) just as expected, except it also generates some files, like PDB, and some CS files. I know what most of them do, but if I am making a software, which consists of multiple of these files, I wouldn't want or like some people looking at the application directory and find source files and/or source code and solutions. This makes me come up with a question: Would deleting every single file except the compiled EXE or DLL impact their usability, or is there any other circumstance(s) to avoid creating these files, like SLN or PDB?
Thanks in advance :)
I have not tried anything, because, I simply don't know how to prevent VS from creating these files, except compiled files.
The .pdb files are outputs of your compilation. You can suppress them with:
<DebugSymbols>false</DebugSymbols>
The other files, like .cs and .sln are inputs to your project. Deleting them will mean you cannot build your program any more. I don't understand why you would want them to be deleted. If they're appearing in your output directory, check that you don't have "Copy local" (CopyToOutputDirectory) set on those items in your project.
I have a generally question about "custom build tool" tab in settings.
I already used this feature and like it. But this time the result is not what I expected :/
I try to automatically convert a Performance Monitor manifest file (.man) to a corresponding .h and .rc file (ctrpp.exe). But this should not matter, just about the principle.
After I assign the custom step to the .man file, it is possible to compile the file in context menu. The build tool also recognize a modification and builds the output files again. Also the output files were deleted at rebuild.
But that's my problem.
Manual compile and inkremental build works fine, but why the files wasn't build automaticall after a first check out or at rebuild?? I expected that compiler forces a build, if it no output files found.
As result, the compiler don't find the corresponding header file in my files.
This page (in German) describes when the update is triggered. Can I force to generate the output files?
I have a solution where there is a dependency on 7zip's sfx. Out of desire to keep the entire solution (plus the sfx) managed and coordinated, I want to create a new project to house all the source files that is used by sfx, and when building, execute a command line that tells 7zip to build a sfx from the source files, and place into the output so that it can be then referenced by actual Visual Studio projects within the same solution.
I think I can figure the command line by using Build events and providing the appropriate macros to ensure that the 7zip's output is placed into the target folder with appropriate name so that it can be then correctly referenced by other VS projects. But what I am not sure about is what Visual Studio project I need to use or steps to take to tell Visual Studio that there isn't going to be any code to be compiled in this project and it just has to execute this script I give it.
The closest thing I can come up with is VS's Make project but I don't know if that is the right thing since this has nothing to do with Make at all.
So, what is the Visual Studio project template I need to use? If empty, then what configuration do I need to perform so that it won't try and look for some code files to compile but instead just execute scripts as part of the solution's build?
For now, it seems that using C++ Makefile Project works. I had to make few configurations:
1) I had to specify the project's "Configuration Type" as "Utility"
2) I used Pre-Build event and provided a command to invoke a batch file included in the project. The batch file then takes care of everything.
3) Normally, non C++ files are not considered for determining whether build is needed or if it's already up to date. To ensure that a new build is perform if the batch file or other key files are edited, I set the file's "File Type" to "MakeFile". Even though it isn't actually a Make file, it ensures that any edits made to the file will cause a new build.
The downsides I've found so far are:
1) C++ uses "Filters", not folders. Therefore, keeping the files in same directory structure is a big PITA. One can "include" files and get a one-to-one mapping between "Filters" and the actual directory structure on disk but it's annoying and tedious. Wish it was a C# project
2) I'm a bit wary about how it will detect new files or other changes for files that I didn't explicitly set to "MakeFile". I expect the source to be stable but I worry that when I realize I need a new file and add it, I might forget and not notice that the build is not correctly including the new file.
I'm not sure if this is the best method but this works for my purpose - having a project to manage external tools as part of bigger build process.
Codeblocks cannot find definitions or declarations of some functions in my project.
Question: Is there a way to force a re-scan of the source tree?
I believe that all of the relevant files are included into the project.
(Just checked: it cannot find by name a struct declared in an opened file.)
First, let me give a couple of ways to help C::B find your declarations/definitions.
Although somewhat obvious, you should make sure the function is in a file that is either:
1) part of the project itself (i.e. it should be shown in the projects->workspace window). If you intended it to be part of the project but it isn't there, then go to project->add files and add the file.
2) If you don't want/need the file to be part of the project but you still want to access the declarations/definitions, you need to let the project manager know where to find the file. You can do this in project->build options and set the search directories. Be careful when setting the search directories...you can set it for the whole project or build target (debug or executable).
Note: one common problem occurs when you have multiple projects open in C::B. Even though all your projects are "open", there is only one that is "activated". So, just because you have a file open, it doesn't mean the file is part of the activated project. You can do search-->open files" which will find code in a file if it's open but not in the current active project.
The only way to "re-scan", is to rebuild your project after making changes in the source code or project settings. You may have to restart C::B. If you still can't find the declaration/definition after doing the above, I would suggest you make a sample program and see if it will find the declaration/definition. If it does, then you can check the settings between your project and the sample project. In the worst case, you can copy your code from your project to the sample project. If that doesn't work, you can reinstall C::B and try again. Not fun but sometimes it works.
You can try, rebuilding the project, but make sure at least one other file includes the header for the structure or make sure the header and source file are included in the project.
I have a COM project that contains a number of IDL files, some of which are imported into other ones. How does Visual Studio decide which ones to compile (using MIDL) first?
I want to control the order. I have a master IDL file which contains my library declaration with several imports, and I get a build error if it is not the first one compiled.
(If any of this sounds really weird... I'm new to COM/ATL, and it's really, really confusing).
You can't ask Visual Studio to build .ild files in a specific order. Instead you can #include some of .idl files into other .idl files and set the files you imported to "excluded from build". This way MIDL will not compile the imported files separately, instead it will include their contents into specific place of another file and compile as the part of that file (same effect as with C preprocesor #include).
You can make Visual Studio build things in any order you want, there are 2 ways to do this:
Put in a pre-build step in which you can get it to build the ones you wish to build first.
Put the ones you want to build first in a separate project and get it to build that project first by making your other one dependent on it.
This is what you should do if you cannot modify the idl files. If however one idl file really does depend on another and you can modify them, then do what was suggested above and get one to include the other.