You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 5, 2019. It is now read-only.
FLAVOR_WIN appears to be undefined? or did I miss something?
Do we need add back in the lines to set the default FLAVOR_WIN to init.cmd?
tools\scripts\init.cmd script in the past defined two environment variables FLAVOR_DAT and FLAVOR_WIN as follows:
if /I "%FLAVOR_DAT%" == "Debug" set FLAVOR_DAT=Debug
if /I "%FLAVOR_DAT%" == "Release" set FLAVOR_DAT=Release
if "%FLAVOR_DAT%" == "" set FLAVOR_DAT=Release
if /I "%FLAVOR_WIN%" == "Debug" set FLAVOR_WIN=Debug
if /I "%FLAVOR_WIN%" == "Release" set FLAVOR_WIN=Release
if "%FLAVOR_WIN%" == "" set FLAVOR_WIN=Release
In init.cmd in MF v4.4, the above lines defining a default for FLAVOR_WIN have been removed leaving FLAVOUR_DAT alone.
FLAVOR_WIN is used later in the same init.cmd and it has not been defined.
set BUILD_TREE_SERVER=%BUILD_ROOT%\%FLAVOR_WIN%\server
also in setenv_base.cmd
set PATH=%CLRROOT%\BuildOutput\Public\%FLAVOR_WIN%\Test\Server\dll;%PATH%
Please can we clarify the intended use for the following
FLAVOR
Configuration
FLAVOR_DAT
FLAVOR_WIN
MSBuild will use local values defined in Microsoft.SPOT.Build.Setup.Targets, which can result in different values for BUILD_TREE etc. to those defined in the environment variables. Can be confusing when switching between Debug and Release builds.
To build a debug version of MF and solution, would appear one needs to:
set FLAVOR=Debug
set Configuration=Debug
set FLAVOR_WIN=Debug
set FLAVOR_DAT=Debug
setenv_ds5 5.05
build_sdk
cd Solutions\<platformname>
msbuild /flp:verbosity=detailed /clp:verbosity=minimal
cd ..\..
msbuild /flp:verbosity=detailed /clp:verbosity=minimal build.dirproj
%BUILD_TEST_TREE_SERVER%\dll\RunTests.exe
Not that build_sdk.cmd has /p:FLAVOR=RTM, so to strictly do all debug build, need a buildDebug_sdk.cmd with RTM replaced with Debug or deleted to let it pick up the environment variable.
Maybe for V4.4 add FLAVOR_WIN to init.cmd
Possibly consider replication of logic that uses FLAVOR and Configuration to set FLAVOR_WIN and FLAVOUR_DAT into init.cmd?
Maybe I am just confused and need a wiki page to explain things?
You wouldn't be the only one confused! The whole nonsense of Flavors, configurations, etc...has been a HUGE source of problems and attempts to clean up and simplify it end up causing troubles. (The only way out I know of is a complete re-write of the build infrastructure to used proper VCXPROJ for native code and CSPROJ, etc.. for managed). I'll do my best to explain the insanity:
FLAVOR -> Build "flavor) Release, Debug, etc... for Device target code
Configuration -> standard Visual Studio Project configuration, for projects that are proper VS projects (e.g. CSPROJ and VBPROJ)
FLAVOR_WIN => Build flavor for the Windows based tools, libs, dlls and assemblies. That is if it runs on the desktop, this is what determines the build type (debug, release, etc...). This is also used when building target binaries to determine the location of the tools to perform the actual build.
FLAVOR_DAT determines the build flavor for the "built-in" assemblies this is used to determine the path used to create the flash image binary of the PE files. Generally this is the same as FLAVOR.
In the build system FLAVOR_WIN defaults to FLAVOR if it isn't already set.
FLAVOR_WIN appears to be undefined? or did I miss something?
Do we need add back in the lines to set the default FLAVOR_WIN to init.cmd?
tools\scripts\init.cmd script in the past defined two environment variables FLAVOR_DAT and FLAVOR_WIN as follows:
In init.cmd in MF v4.4, the above lines defining a default for FLAVOR_WIN have been removed leaving FLAVOUR_DAT alone.
FLAVOR_WIN is used later in the same init.cmd and it has not been defined.
also in setenv_base.cmd
It is referenced in many other project files..
"Microsoft.SPOT.Support.Settings" are not included as per the commented out Import in "Microsoft.SPOT.Build.Setup.Targets"
The text was updated successfully, but these errors were encountered: