The issue was in fact paths. Operating with in the Developer Command Prompt
for VS2013 requires a path of:
C:\cwgwin64\bin;C:\cygwin64\usr\bin
Reason: coreutils which contains printf and a host of other bash commands
resides in C:\cygwin64\bin. Flex and Bison are installed in
C:\cygwin64\usr\bin.
So from Developer Command Prompt for VS2013 you can reach printf and flex
and bison.
Now the kicker if you now open the Cygwin64 Terminal the aforementioned
C:\cygwin64\bin and C:\Cygwin64\usr\bin are mangled by cygwin64's remake of
the path into the form /cygdrive/c/...
and writes usr/bin;usr/bin in the path which breaks the path in
Cygwin64 Terminal.
If you don't include C:\cygwin64\bin and C:\Cygwin64\usr\bin in the path
then cygwin64 is smart enough to figure it out and printf works in the
Cygwin64 Terminal but, now it is broken in the Developer Command Prompt
for VS2013.
I'm thinking a workaround for this is to begin each windows batch file with
a path command the appends C:\cwgwin64\bin;C:\cygwin64\usr\bin but do not
put those in the system path.
On Mon, Feb 2, 2015 at 12:25 PM, Oz Linden (Scott Lawrence) <
o...@lindenlab.com> wrote:
> On 2015-01-31 17:38 , Nicky Perian wrote:
>
> Anyone know what causes this on a release build?
> Doesn't stop the build and the installer is still made.
> 3>------ Build started: Project: generate_viewer_version, Configuration:
> Release Win32 ------
> 3> processing
> 3> 'printf' is not recognized as an internal or external command,
> 3> operable program or batch file.
> 3>C:\Program Files
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets(170,5):
> error MSB6006: "cmd.exe" exited with code 9009.
>
> Appears to come from newview/CMakeLists.txt
> source_group("CMake Rules" FILES ViewerInstall.cmake)
>
> # the viewer_version.txt file created here is for passing to
> viewer_manifest and autobuild
> # the summary.json file is created for the benefit of the TeamCity builds,
> where
> # it is used to provide descriptive information to the build results page
> add_custom_target(generate_viewer_version ALL
> COMMAND printf
> '${VIEWER_SHORT_VERSION}.${VIEWER_VERSION_REVISION}' >
> ${CMAKE_CURRENT_BINARY_DIR}/viewer_version.txt
> COMMAND printf
> '{"Type":"viewer","Version":"${VIEWER_SHORT_VERSION}.${VIEWER_VERSION_REVISION}"}'
> > ${CMAKE_BINARY_DIR}/summary.json
> COMMENT Generating viewer_version.txt for manifest
> processing
> )
>
>
> That looks like cmake is trying to run commands in a windows shell rather
> than bash; the printf is a bash command. This works in our build
> environment. It's possible that it could be replaced with cmake FILE
> commands?
>
> --
> *Oz Linden (Scott Lawrence)* | *Engineering Director, Second Life*
> Email or Hangouts o...@lindenlab.com | Second Life Oz Linden
> <https://my.secondlife.com/oz.linden>
> Linden Lab | Makers of Shared Creative Spaces <http://lindenlab.com/>
> Check out what we're working on! <http://lindenlab.com/products>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
