Skip to content
This repository has been archived by the owner on Jun 5, 2019. It is now read-only.

build_solution for GCC #521

Open
josesimoes opened this issue Oct 25, 2016 · 7 comments
Open

build_solution for GCC #521

josesimoes opened this issue Oct 25, 2016 · 7 comments

Comments

@josesimoes
Copy link
Contributor

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:

@echo off
setlocal
call setenv_%1 %2 %3
cd Solutions\%4
msbuild /flp:verbosity=detailed /clp:verbosity=minimal %~5
endlocal&&exit /B %ERRORLEVEL%

can anyone please double check this and also confirm if this causes any issues with MDK?

Thanks!

@smaillet-ms
Copy link
Member

smaillet-ms commented Oct 25, 2016

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:
MDK 5.05 MCBSTM32F400

For GCC it uses an additional parameter to specify the project to build (relative to the solution folder):
GCC 4.9.3 MCBSTM32F400 TinyClr_nonet\Tinyclr_nonet.proj
and again with:
GCC 4.9.3 MCBSTM32F400 TinyClr_nonet\Tinyclr_nonet.proj
to validate the known GCC builds complete (which they don't , which is why the build status indicates partial success)
The additional and optional 4th parameter allows targeting a specific MSBuild project, if the extra parameter is not present then MSBuild will use the project file in the solution directory. If more then one exists it returns an error indicating that there is more than one and you need to specify which one you want.

@josesimoes
Copy link
Contributor Author

josesimoes commented Oct 25, 2016

@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
setting vars for GCC compiler GCC5.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
Example: setenv_gcc.cmd 4.2.1 c:\tools\gcc

A correct call has to be something like:
build_solution gcc 5.4.1 E:\GNU_Tools_ARM_Embedded\5_4_2016q2 STM32F4DISCOVERY

@smaillet-ms
Copy link
Member

I think the better fix is in setenv_base:
in this area:

rem use a default for GCC

IF "%ARG3%"=="" (

    SET "ARG3=%SystemDrive%\gnu\gcc"

    IF NOT EXIST "%ARG3%" set "ARG3=%ProgramFiles(x86)%\GNU Tools ARM Embedded\4.9 2015q1"

)

IF NOT EXIST "%ARG3%" GOTO :BAD_GCC_ARG

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.

@josesimoes
Copy link
Contributor Author

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?

@cw2
Copy link
Contributor

cw2 commented Oct 25, 2016

@josesimoes You can try tweaking the batch parameters with quoted strings (%~ to dequote, already used for the last msbuild parameter %~4):

call setenv_%1 %~2

which would allow you to pass GCC version and path

build_solution GCC "5.4.1 C:\GCC" SolutionName

You can use ^ escape character for embedded quotes : )

@smaillet-ms
Copy link
Member

smaillet-ms commented Oct 25, 2016

@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.

@josesimoes
Copy link
Contributor Author

josesimoes commented Oct 26, 2016

@smaillet-ms I think @cw2 suggestion above would solve this without braking anything and not requiring adding any environment vars.
And adding an hint for the correct usage would be helpful to people using GCC.
I've submitted PR #522 adding an explanation and examples and PR #523 for the script. Feel free to change that to something more meaningful or a better explanation.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants