Sysprogs forums › Forums › VisualGDB › Always run a program before build
- This topic has 2 replies, 2 voices, and was last updated 3 hours ago by
murrellr.
-
AuthorPosts
-
July 14, 2025 at 12:31 #36805
murrellr
ParticipantI have a prebuild step that runs a program to examine certain files and generates a C include file used by our product build. The program was originally a Windows batch file that populated a directory and then a custom utility was executed that generates the include file. I ran this batch file as a pre-build step. This caused some problems in that the scanned files were outside of Visual Studio so the include file did not automatically get generated when one of the scanned files changed. Also, the batch file was fairly dumb in that it always generated the include file even if there were no changes.
Recently some large files were added to the list and the batch file takes a long time to run. So I converted the batch file into a Makefile to make the generating of the include file smarter. This still has the problem that scanned file changes don’t trigger a build. Visual Studio has a mechanism for assigning custom build tools but VisualGDB seems to be suppressing the capability. So now I’m stuck trying to figure out the best way to automate the build of our product.
Here is what the Makefile is doing using Windows CMD commands:
- Generate a list of individual files with relative paths from the contents of a text file. The text file lines can include wildcards that mean “all the files in the current directory and below”.
- Compare the list of files to a zipped file in the staging directory. If the zip file is out-of-date, regenerate it in the staging directory.
- Blind copy another pre-built zip file into the staging directory.
- Generate a list of individual files with paths from another text file. This file can also have wildcard entries. The zip files in the staging directory are also included in the list.
- If any of these files are out-of-date with the include file, copy all the files into the staging directory and regenerate the include file.
It seems that I should be able to include these steps directly into the project, but I’m dealing with lists of files with arbitrary extensions generated from wildcard strings and custom actions for building. Visual Studio doesn’t seem to handle that well. The next best thing would be to always build the Makefile before Visual Studio scans for out-of-date files, but that seems difficult to do under VisualGDB.
Any suggestion on how I can handle this situation?
July 14, 2025 at 12:41 #36806support
KeymasterHi,
The VisualGDB’s logic for transferring files to the target is completely separate from the contents of the .vcxproj files. So, you can set it up like this:
- Run the custom Makefile as a custom pre-sync step (not pre-build step). It will run before VisualGDB computes which files need to be uploaded to the build machine.
- Ensure the file synchronization settings reference all relevant directories. They don’t have to be inside the project directory. You can configure VisualGDB to arbitrarily upload everything in $(ProjectDir)\..\shared to $(BuildDir)/../shared, and it will handle it just fine, even if some files in shared were just updated by the custom pre-sync step.
You can also have a mix of custom Make invocations and custom file upload jobs in the pre-build steps or as manually invokable custom shortcuts, if you want to make the entire setup more modular, and reduce the amount of files checked/updated at once.
July 16, 2025 at 12:45 #36811murrellr
ParticipantThank you for responding. I’m not sure what you mean by “pre-sync step”. I see a “Synchronized Directories” menu on the VisualGDB properties page, but it is disabled. I should note that the project is an MSBuild project and all the files are located on my Windows PC in a Git repository. The resultant header file compiles the file contents in our application and the files are never deployed directly to the target system.
-
This reply was modified 3 hours ago by
murrellr.
-
AuthorPosts
- You must be logged in to reply to this topic.