-
Notifications
You must be signed in to change notification settings - Fork 224
build_solution for GCC #521
Comments
No idea - what branch are you based off of? The current dev branch version of build_solution doesn't have that. The automated build calls build_solution with the following args for the MDK build: For GCC it uses an additional parameter to specify the project to build (relative to the solution folder): |
@smaillet-ms yes, the current version does not have that and it fails to build a solution based with GCC. That's why I've raised this question. I'm on the dev branch. I can only make it work with that 3rd parameter, otherwise it fails complaining with an invalid argument Compiler: GCC 5.4.1 Error - Invalid argument (C:\Program Files (x86)\GNU Tools ARM Embedded\4.9 2015q1). Usage: setenv_GCC.cmd GCC_VERSION GCC_TOOL_PATH A correct call has to be something like: |
I think the better fix is in setenv_base:
Instead of immediately trying the legacy defaults, it can test for an Environment var that can be set once for the system to indicate the tool location. Having multiple optional params on a CMD script makes things complicated. The tool path is generally not needed for MDK builds. |
Got you. Question: can't be problematic relying on an environment var on a build machine that you might not have enough control to add that environment var? Shouldn't paths such as this be in a config file (exclusive on NETMF) that is read/parsed when the build process launches? |
@josesimoes You can try tweaking the batch parameters with quoted strings (
which would allow you to pass GCC version and path
You can use |
@josesimoes ENV vars are already used in the build servers to provide tool locations (among other things) At present for GCC, the build server and scripts rely on the default install paths from the tool installers, so no additional path is required. ANY change to the input arguments of build_solution (or build_sdk) necessitates changes in the automated build process. Ideally none of these horrific setenvxxx scripts would be needed, BuildEnv.props was the start of that but various other aspects of 4.4 ended up taking a higher priority and I never got back to fully eliminating the environment scripts. |
@smaillet-ms I think @cw2 suggestion above would solve this without braking anything and not requiring adding any environment vars. |
I'm failing to use the current version of the build_solution to build a solution with GCC.
It seems to require an extra argument in 3rd line "call setenv_%1 %2 _%3_" like this:
can anyone please double check this and also confirm if this causes any issues with MDK?
Thanks!
The text was updated successfully, but these errors were encountered: