Forum Replies Created
-
Posts
-
Just in case someone needs this information in the future, what I did was this:
Command: cmd.exe
Arguments: /c py -3 “\_build\pre_build.py” (or whatever/wherever your python script is)
The “/c” is essentially telling the command line to execute the string passed to it. In this way, it will search PATH for py.exe
Fair point. For someone (or me!) who is looking at this in the future, TeamCity sets a bunch of environment variables by itself, so the pre-build step can inspect to see if the environment variable exists or not, and use that. TeamCity sets BUILD_NUMBER to the build number as well as other variables that may be useful such as the commit hash, project name, etc. To see what is available, have the build server send “set” so the log will contain all the environment variables.
How would this be done, then? I have my Build Server pre-build step that executes a command line to say “set BUILDVER=5”, but when it calls msbuild, wouldn’t that environment variable no longer be active since its in a separate command line window because it is a separate build step?
After spending an inordinate amount of time on this, I fixed the issue by deleting my PreBuild action and then recreating it. Attached is an image comparing the vgdbsettings file change that made it happen. What could cause this? Is this just a stupid error on my part?
So by doing this, here is the hierarchy and breakdown:
- devenv.exe (Path is present)
- MSBuild.exe (Path is *not present*)
- vgagent.exe (Path is *not present*)
- cmd.exe (Path is *not present*)
- notepad.exe (Path is *not present*)
- cmd.exe (Path is *not present*)
- vgagent.exe (Path is *not present*)
- MSBuild.exe (Path is *not present*)
What are the next steps to work around this?
None of the other variables get overridden, just ‘path’ which is now empty. I noticed that if I open the project via Visual Studio (Start–>Visual Studio 2017, and then doing File->Open->Solution), I now have access to ‘path’. If I have *never* opened it that way, but only just opened it by double-clicking the solution, then the path is missing.
Way to reproduce (for me):
- Take a working project
- Copy and paste the project (so it creates a new folder. can be in the same directory.)
- Double-click the solution
- Create a pre-build batch file that just has “set” or “python -h” in it.
- Build the project
- The project will not show path as a system env variable. It will also complain about not being able to find python (due to missing path).
- Open Visual Studio Start->Visual Studio 2017
- Open solution
- Build project again. Now you will see that it does have the path variable and “python -h” shows the appropriate python help info.
Can you reproduce it with this? You can try one of your own projects, but be sure to do a copy/paste.
In case someone comes across this in the future like I did, here is what you need to do:
-Include the cmsis_os.c/.h files from “\Middlewares\Third_Party\FreeRTOS\Source\CMSIS_RTOS”
-Add the port.c and portmacro.h files from “\Middlewares\Third_Party\FreeRTOS\Source\portable\GCC\ARM_CM7\r0p1”
Awesome, new build works great. The syntax highlighting as part of variable renaming preview is not that big of a deal.
I just submitted the PO so it should be renewed today or tomorrow. I fixed the issue by uninstalling/reinstalling visual studio and then VisualGDB. Just reinstalling VS didn’t fix it for some reason. I also deleted and reinstalled all the VGDB packages as well. Now it is all set.
I tried using a Nucleo board with the onboard ST Link and I am having the same problem (working on desktop, not on laptop). Is there anything that is PC specific that could allow programming to work but not Fast Semihosting? I didn’t mention it before, but I am able to run the project without a problem if I comment out my printf statements.
- devenv.exe (Path is present)
