Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Juan E. Sanchez]

Hello,

Perhaps you can start by not using the .bat scripts and using the .exe 
instead.  You can run cmake from a visual studio environment, and 
instead of invoking a visual studio environment for each command.


And to build from your script:
cmake --build .

Regards,

Juan


On 9/19/19 12:59 PM, Joao Pedro Abreu De Souza wrote:

Now, with this toolchain file:
-start of toolchain file---
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR "x86")
set(CMAKE_SYSTEM_VERSION 1)

# Microsoft MSVC compiler
#set(CMAKE_C_COMPILER cl.exe)
#set(CMAKE_CXX_COMPILER cl.exe)

set(CMAKE_C_COMPILER 
"${CMAKE_CURRENT_SOURCE_DIR}/ninja-core-lib/toolchains/cl.bat")

set(CMAKE_CXX_COMPILER "${CMAKE_C_COMPILER}")

# Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
# so tell CMake that cl.exe supports C99
set(CMAKE_C_COMPILE_FEATURES c_std_99)


set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")



#set(CMAKE_STATIC_LINKER link.exe)
#set(CMAKE_LINKER link.exe)
#set(CMAKE_SHARED_LINKER link.exe)

set(CMAKE_STATIC_LINKER 
"${CMAKE_CURRENT_SOURCE_DIR}/ninja-core-lib/toolchains/link.bat")

set(CMAKE_LINKER ${CMAKE_STATIC_LINKER})
set(CMAKE_SHARED_LINKER ${CMAKE_STATIC_LINKER})


set(CMAKE_AR ${CMAKE_LINKER})

set(CMAKE_C_COMPILER_ID "porquePreciseiDeUmBat")
-stop of toolchain file---

using this cl.bat
start of cl.bat-
pushd
"C:/Program Files (x86)/Microsoft Visual 
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"

popd
cl.exe %*
stop of cl.bat-

and link.bat in the same spirit but with link.exe instead of cl.exe, I 
can execute cmake, ninja, but the main.exe don't are on build/src/main



When I look on CMakeError.log on build directory, can look

---start of CMakeError.log--
C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles>more 
CMakeError.log
Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
did not produce an executable in 
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".


Checking whether the C compiler is IAR using "" did not match "IAR .+ 
Compiler":


C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>pushd

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>"C:/Program 
Files (x86)/Microsoft Visual 
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"

**
** Visual Studio 2017 Developer Command Prompt v15.9.16
** Copyright (c) 2017 Microsoft Corporation
**
[vcvarsall.bat] Environment initialized for: 'x64_x86'
Checking whether the C compiler is IAR using "" did not match "IAR .+ 
Compiler":


C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>pushd

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>"C:/Program 
Files (x86)/Microsoft Visual 
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

Now, with this toolchain file:
-start of toolchain file---
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR "x86")
set(CMAKE_SYSTEM_VERSION 1)

# Microsoft MSVC compiler
#set(CMAKE_C_COMPILER cl.exe)
#set(CMAKE_CXX_COMPILER cl.exe)

set(CMAKE_C_COMPILER
"${CMAKE_CURRENT_SOURCE_DIR}/ninja-core-lib/toolchains/cl.bat")
set(CMAKE_CXX_COMPILER "${CMAKE_C_COMPILER}")

# Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
# so tell CMake that cl.exe supports C99
set(CMAKE_C_COMPILE_FEATURES c_std_99)


set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")



#set(CMAKE_STATIC_LINKER link.exe)
#set(CMAKE_LINKER link.exe)
#set(CMAKE_SHARED_LINKER link.exe)

set(CMAKE_STATIC_LINKER
"${CMAKE_CURRENT_SOURCE_DIR}/ninja-core-lib/toolchains/link.bat")
set(CMAKE_LINKER ${CMAKE_STATIC_LINKER})
set(CMAKE_SHARED_LINKER ${CMAKE_STATIC_LINKER})


set(CMAKE_AR ${CMAKE_LINKER})

set(CMAKE_C_COMPILER_ID "porquePreciseiDeUmBat")
-stop of toolchain file---

using this cl.bat
start of cl.bat-
pushd
"C:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
popd
cl.exe %*
stop of cl.bat-

and link.bat in the same spirit but with link.exe instead of cl.exe, I can
execute cmake, ninja, but the main.exe don't are on build/src/main


When I look on CMakeError.log on build directory, can look

---start of CMakeError.log--
C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles>more
CMakeError.log
Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Compilation of the C compiler identification source "CMakeCCompilerId.c"
did not produce an executable in
"C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/3.15.3/CompilerIdC".

Checking whether the C compiler is IAR using "" did not match "IAR .+
Compiler":

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>pushd

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>"C:/Program
Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
**
** Visual Studio 2017 Developer Command Prompt v15.9.16
** Copyright (c) 2017 Microsoft Corporation
**
[vcvarsall.bat] Environment initialized for: 'x64_x86'
Checking whether the C compiler is IAR using "" did not match "IAR .+
Compiler":

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>pushd

C:\Users\jpabreu\Desktop\testCMAKE\build_Win32_normal\CMakeFiles\3.15.3\CompilerIdC>"C:/Program
Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Auxiliary/Build/vcvarsamd64_x86.bat"
**
** Visual Studio 2017 Developer Command Prompt v15.9.16
** Copyright (c) 2017 Microsoft Corporation
**
[vcvarsall.bat] Environment initialized for: 'x64_x86'
Detecting C compiler ABI info failed to compile with the following output:
Change Dir:
C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Gonzalo Garramuño]

El 17/9/19 a las 16:46, fdk17 escribió:


I personally never seen anyone try to use the Ninja generator via 
command line CMake and use the cl.exe compiler.
I've only seen that using Visual Studio to open a CMakeLists.txt file 
it can produce a Ninja project.  But even MS documentation states that 
it doesn't always work.


I use it just like that.  I open a .bat file that calls vsvars with the 
right settings and then calls msys bash. Find it below:



@echo off

call "C:/Program Files (x86)/Microsoft Visual Studio 
14.0/VC/vcvarsall.bat" amd64 8.1

C:
C:\MinGW\msys\1.0\msys.bat -rxvt

Then I call cmake and ninja with a bash script (both are in the bash 
PATH).  Find it attached.



--

Gonzalo Garramuño

#!/bin/bash

#
# Determine CPU architecture
#
KERNEL=`uname -s`

if [[ $KERNEL == CYGWIN* ]]; then
KERNEL=Windows
RELEASE=(`cmd /c 'ver'`)
RELEASE=${RELEASE[3]%.[0-9]*}
elif [[ $KERNEL == MINGW* ]]; then
RELEASE=(`cmd /c 'ver'`)
#RELEASE=${RELEASE[3]%.[0-9]*}
RELEASE=${RELEASE[3]/]/}
KERNEL=Windows
else
RELEASE=`uname -r`
fi


if [[ "$RELEASE" == "" ]]; then
$RELEASE=`cmd.exe /c 'ver'`
echo $RELEASE
echo "Could not determine OS version"
exit 1
fi

CMAKE_OPTS=${CMAKE_OPTS=""}

export CMAKE_NATIVE_ARCH=32
export CMAKE_BUILD_TYPE=Release
export CMAKE_PROCS=8
export OS_32_BITS=1
export OS_64_BITS=

if [ $KERNEL == 'Windows' ]; then
arch=`wmic OS get OSArchitecture`
if [[ $arch == *64* ]]; then
CMAKE_NATIVE_ARCH=64
export OS_64_BITS=1
fi
else
arch=`uname -a`
fi

if [[ $arch == *x86_64* ]]; then
CMAKE_NATIVE_ARCH=64
export OS_64_BITS=1
else
if [[ $arch == *ia64* ]]; then
CMAKE_NATIVE_ARCH=64
export OS_64_BITS=1
unset  OS_32_BITS
fi
fi


export CMAKE_BUILD_ARCH=$CMAKE_NATIVE_ARCH

OS=$KERNEL-$RELEASE


usage()
{
cat <  use a different cmake generator (default: Ninja)

  debug|release|reldebug|small
  debug- build a debug build
  release  - build a release build (default)
  reldebug - build a release build with debug information
  small- build a small release build

  both|32|64
 Builds both 32/64 bit versions, 32-bit only,
 64-bit only (default: $CMAKE_BUILD_ARCH)

  cache- Cleans all CMakeCache.txt files

  swig - Cleans all swig files

  clean- Cleans BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE

  cmake- Runs cmake only.

EOF
exit 1
}

clean_cache()
{
if [ $CMAKE_BUILD_ARCH == 'Both' ]; then
CMAKE_BUILD_ARCH=32
clean_cache
CMAKE_BUILD_ARCH=64
clean_cache
CMAKE_BUILD_ARCH=Both
return
fi

builddir=BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE
if [ ! -d $builddir ]; then
return
fi
echo
echo "Removing old cmake caches $builddir..."
echo
# Remove cache files
find $builddir -name CMakeCache.txt -exec rm {} \;
# Remove makefiles
find $builddir -name Makefile -exec rm {} \;
}


clean_swig()
{
if [ $CMAKE_BUILD_ARCH == 'Both' ]; then
CMAKE_BUILD_ARCH=32
clean_swig
CMAKE_BUILD_ARCH=64
clean_swig
CMAKE_BUILD_ARCH=Both
return
fi

# Remove swig wrappers
builddir=BUILD/$OS-$CMAKE_BUILD_ARCH/$CMAKE_BUILD_TYPE
echo
echo "Removing old swig wrappers $builddir..."
echo
find $builddir -name '*_wrap.*' -exec rm {} \;
}

#
# Parse command-line options
#
clean=0
cache=0


if [[ $OS == Windows* ]]; then
cmake_generator=Ninja
#cmake_generator="NMake Makefiles"
win32cl=`which cl`
if [[ $win32cl != *amd64* ]]; then
CMAKE_BUILD_ARCH=32
fi
else
cmake_generator=Ninja
fi


opts=''
RUN_MAKE=1
for i in $@; do
case $i in
64)
shift
CMAKE_BUILD_ARCH=64
;;
32)
shift
CMAKE_BUILD_ARCH=32
;;
both)
shift
CMAKE_BUILD_ARCH='Both'
;;
cache)
shift
cache=1
;;
clean)
if [ -r CMakeLists.txt ]; then
shift
if [ -d BUILD ]; then
clean=1
fi
else
break
fi
;;
-DCMAKE_INSTALL_PREFIX=*|--installdir=*)
shift
installdir="${i#*=}"
;;
cmake)
shift
RUN_MAKE=0
;;
debug)
shift
export CMAKE_BUILD_TYPE=Debug
;;
release)
shift
export CMAKE_BUILD_TYPE=Release
;;
small)
shift
export CMAKE_BUILD_TYPE=MinSizeRel
;;
swig)
shift
clean_swig
;;
-h)
shift
usage
;;
--help)
shift
usage
;;
-j)
shift
if [ $#

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Eric Doenges]

If the environment is set up correctly, the MSVC tools should be able to 
find the correct versions of the runtime libraries automatically. If you 
are using the wrapper script approach, the problem is most likely that 
when using MSVC, linking is done by calling the linker directly instead 
of indirectly via the compiler driver (as is common on Unix-like 
systems). So you also need a wrapper for link.exe that sets up the 
environment, and tell CMake to use that by setting CMAKE_LINKER to the 
name of the wrapper script.


With kind regards,
Eric

Am 18.09.19 um 18:39 schrieb Joao Pedro Abreu De Souza:
Cool. I try using this toolchain in a toy project, just to test, and 
execute the cmake inside cross-compiling x64_x86 from visual studio 
2017 and all work as expected, except the linking from ninja, that 
break because cannot find printf.
Is absolutely cool, better than my last toolchain. Do you know how Can 
I link with libc from visual studio 2013(that was your example)? From 
location on 2013, the 2017 can be deduced, I think.


To make clear, when I said how to link with libc, is literally the 
path that I don't know , I know that must use libpath(or set LIB 
env variable) with the path, but what path? kkk


Em qua, 18 de set de 2019 às 02:50, Eric Doenges > escreveu:


We use ninja for building on Windows. Our toolchain file for the
MSVC compiler is really simple (this is for MSVC 18.0, 32 bits):

--- SNIP ---

set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR "x86")
set(CMAKE_SYSTEM_VERSION 1)

# Microsoft MSVC compiler
set(CMAKE_C_COMPILER cl.exe)
set(CMAKE_CXX_COMPILER cl.exe)

# Unfortunatly CMake doesn't seem to know anything about the MSVC
compiler,
# so tell CMake that cl.exe supports C99
set(CMAKE_C_COMPILE_FEATURES c_std_99)

# If Visual Studio is selected as generator, only allow VS 2013
if(CMAKE_GENERATOR MATCHES "Visual Studio")
  if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
    message(FATAL_ERROR "Visual Studio generator requires Visual
Studio 12 2013"
  " for this configuration")
  else()
    # Enable parallel builds for Visual Studio Projects with the
/MP flag
    set(_MP_FLAG "/MP")
  endif()
endif()

set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")

--- SNIP ---

However, there is a major snag (naturally, since we're talking
about Windows here) - in order for the Microsoft compiler to work
from the command line, you need to set the correct environment,
and CMake doesn't really give you a good way to do this. You can
set environment variables from CMake, but as the documentation
says "This command affects only the current CMake process, not the
process from which CMake was called, nor the system environment at
large, nor the environment of subsequent build or test processes.".

The solution we use is instead of calling cmake directly, we call
a Perl script that sets up the environment correctly and then
calls cmake for configuration or building. An alternative solution
would be to write a batch script wrapper for cl.exe, something like.

@ECHO OFF
"C:\Program Files (x86)\Microsoft Visual Studio
12.0\VC\vcvarsall.bat" x86
cl.exe %*

and then set this batch script as the C and C++ compiler in CMake
(note that this is untested - I think it should work, but it may
need some extra work).

With kind regards,
Eric

Am 17.09.19 um 21:46 schrieb fdk17:

As I recall for myself, simply using the Visual Studio Generator
with the -A option was all that was needed to build for Win32.
You don't need a toolchain file because the generator already
knows how to setup a Visual Studio Project to target Win32.
Even the documentation for cross-compiling doesn't show a need to
setup toolchain file for cross compiling in this case.

I personally never seen anyone try to use the Ninja generator via
command line CMake and use the cl.exe compiler.
I've only seen that using Visual Studio to open a CMakeLists.txt
file it can produce a Ninja project.  But even MS documentation
states that it doesn't always work.


https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
This says you should be able to open the proper development
window and use Ninja.

The output shows that in the environment you are using it doesn't
even know how to use cl.exe to even determine with compiler it
is.  Maybe not all the proper environment variables and paths are
being set correctly when using the compiler.

--
F
-- 


*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457
695-0 | www.mv

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

Cool. I try using this toolchain in a toy project, just to test, and
execute the cmake inside cross-compiling x64_x86 from visual studio 2017
and all work as expected, except the linking from ninja, that break because
cannot find printf.
Is absolutely cool, better than my last toolchain. Do you know how Can I
link with libc from visual studio 2013(that was your example)? From
location on 2013, the 2017 can be deduced, I think.

To make clear, when I said how to link with libc, is literally the path
that I don't know , I know that must use libpath(or set LIB env
variable) with the path, but what path? kkk

Em qua, 18 de set de 2019 às 02:50, Eric Doenges 
escreveu:

> We use ninja for building on Windows. Our toolchain file for the MSVC
> compiler is really simple (this is for MSVC 18.0, 32 bits):
>
> --- SNIP ---
>
> set(CMAKE_SYSTEM_NAME Windows)
> set(CMAKE_SYSTEM_PROCESSOR "x86")
> set(CMAKE_SYSTEM_VERSION 1)
>
> # Microsoft MSVC compiler
> set(CMAKE_C_COMPILER cl.exe)
> set(CMAKE_CXX_COMPILER cl.exe)
>
> # Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
> # so tell CMake that cl.exe supports C99
> set(CMAKE_C_COMPILE_FEATURES c_std_99)
>
> # If Visual Studio is selected as generator, only allow VS 2013
> if(CMAKE_GENERATOR MATCHES "Visual Studio")
>   if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
> message(FATAL_ERROR "Visual Studio generator requires Visual Studio 12
> 2013"
>   " for this configuration")
>   else()
> # Enable parallel builds for Visual Studio Projects with the /MP flag
> set(_MP_FLAG "/MP")
>   endif()
> endif()
>
> set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
> set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")
>
> --- SNIP ---
>
> However, there is a major snag (naturally, since we're talking about
> Windows here) - in order for the Microsoft compiler to work from the
> command line, you need to set the correct environment, and CMake doesn't
> really give you a good way to do this. You can set environment variables
> from CMake, but as the documentation says "This command affects only the
> current CMake process, not the process from which CMake was called, nor the
> system environment at large, nor the environment of subsequent build or
> test processes.".
>
> The solution we use is instead of calling cmake directly, we call a Perl
> script that sets up the environment correctly and then calls cmake for
> configuration or building. An alternative solution would be to write a
> batch script wrapper for cl.exe, something like.
>
> @ECHO OFF
> "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
> cl.exe %*
>
> and then set this batch script as the C and C++ compiler in CMake (note
> that this is untested - I think it should work, but it may need some extra
> work).
>
> With kind regards,
> Eric
> Am 17.09.19 um 21:46 schrieb fdk17:
>
> As I recall for myself, simply using the Visual Studio Generator with the
> -A option was all that was needed to build for Win32.
> You don't need a toolchain file because the generator already knows how to
> setup a Visual Studio Project to target Win32.
> Even the documentation for cross-compiling doesn't show a need to setup
> toolchain file for cross compiling in this case.
>
> I personally never seen anyone try to use the Ninja generator via command
> line CMake and use the cl.exe compiler.
> I've only seen that using Visual Studio to open a CMakeLists.txt file it
> can produce a Ninja project.  But even MS documentation states that it
> doesn't always work.
>
>
> https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
> This says you should be able to open the proper development window and use
> Ninja.
>
> The output shows that in the environment you are using it doesn't even
> know how to use cl.exe to even determine with compiler it is.  Maybe not
> all the proper environment variables and paths are being set correctly when
> using the compiler.
>
> --
> F
>
> --
>
> *Dr. Eric Dönges*
> Senior Software Engineer
>
> MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
> doen...@mvtec.com  | Tel: +49 89 457 695-0 |
> www.mvtec.com
>
> Find our privacy policy here .
>
>  Sign up  for our MVTec Newsletter!
>
> Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
> Amtsgericht München HRB 114695
>
>
> [image: MVTec Software GmbH Logo]
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensourc

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Eric Doenges]

We use ninja for building on Windows. Our toolchain file for the MSVC 
compiler is really simple (this is for MSVC 18.0, 32 bits):


--- SNIP ---

set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_SYSTEM_PROCESSOR "x86")
set(CMAKE_SYSTEM_VERSION 1)

# Microsoft MSVC compiler
set(CMAKE_C_COMPILER cl.exe)
set(CMAKE_CXX_COMPILER cl.exe)

# Unfortunatly CMake doesn't seem to know anything about the MSVC compiler,
# so tell CMake that cl.exe supports C99
set(CMAKE_C_COMPILE_FEATURES c_std_99)

# If Visual Studio is selected as generator, only allow VS 2013
if(CMAKE_GENERATOR MATCHES "Visual Studio")
  if(NOT CMAKE_GENERATOR MATCHES "Visual Studio 12 2013")
    message(FATAL_ERROR "Visual Studio generator requires Visual Studio 
12 2013"

  " for this configuration")
  else()
    # Enable parallel builds for Visual Studio Projects with the /MP flag
    set(_MP_FLAG "/MP")
  endif()
endif()

set(CMAKE_C_FLAGS_INIT   "/arch:SSE2 ${_MP_FLAG} /EHsc")
set(CMAKE_CXX_FLAGS_INIT "/arch:SSE2 ${_MP_FLAG}")

--- SNIP ---

However, there is a major snag (naturally, since we're talking about 
Windows here) - in order for the Microsoft compiler to work from the 
command line, you need to set the correct environment, and CMake doesn't 
really give you a good way to do this. You can set environment variables 
from CMake, but as the documentation says "This command affects only the 
current CMake process, not the process from which CMake was called, nor 
the system environment at large, nor the environment of subsequent build 
or test processes.".


The solution we use is instead of calling cmake directly, we call a Perl 
script that sets up the environment correctly and then calls cmake for 
configuration or building. An alternative solution would be to write a 
batch script wrapper for cl.exe, something like.


@ECHO OFF
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
cl.exe %*

and then set this batch script as the C and C++ compiler in CMake (note 
that this is untested - I think it should work, but it may need some 
extra work).


With kind regards,
Eric

Am 17.09.19 um 21:46 schrieb fdk17:
As I recall for myself, simply using the Visual Studio Generator with 
the -A option was all that was needed to build for Win32.
You don't need a toolchain file because the generator already knows 
how to setup a Visual Studio Project to target Win32.
Even the documentation for cross-compiling doesn't show a need to 
setup toolchain file for cross compiling in this case.


I personally never seen anyone try to use the Ninja generator via 
command line CMake and use the cl.exe compiler.
I've only seen that using Visual Studio to open a CMakeLists.txt file 
it can produce a Ninja project.  But even MS documentation states that 
it doesn't always work.


https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
This says you should be able to open the proper development window and 
use Ninja.


The output shows that in the environment you are using it doesn't even 
know how to use cl.exe to even determine with compiler it is.  Maybe 
not all the proper environment variables and paths are being set 
correctly when using the compiler.


--
F

--

*Dr. Eric Dönges*
Senior Software Engineer

MVTec Software GmbH | Arnulfstr. 205 | 80634 Munich | Germany
doen...@mvtec.com  | Tel: +49 89 457 695-0 
| www.mvtec.com 


Find our privacy policy here .

Sign up  for our MVTec Newsletter!

Geschäftsführer: Dr. Wolfgang Eckstein, Dr. Olaf Munkelt
Amtsgericht München HRB 114695

MVTec Software GmbH Logo
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

Well, the Visual Studio Generator alone is not a option because the
repository has a actual build system(a bunch of bat files that call a
python script that generate ninja files).
We want to change to cmake, and now we don't use Visual Studio a lot. Most
of time, we only need their compiler and linker.

Well, Thanks all for the attention, sorry about the time wasted. I will
continue to search to exactly options and, in case of sucess, mail here
again.
Great day to all of you.

Em ter, 17 de set de 2019 às 16:56, fdk17  escreveu:

> As I recall for myself, simply using the Visual Studio Generator with the
> -A option was all that was needed to build for Win32.
> You don't need a toolchain file because the generator already knows how to
> setup a Visual Studio Project to target Win32.
> Even the documentation for cross-compiling doesn't show a need to setup
> toolchain file for cross compiling in this case.
>
> I personally never seen anyone try to use the Ninja generator via command
> line CMake and use the cl.exe compiler.
> I've only seen that using Visual Studio to open a CMakeLists.txt file it
> can produce a Ninja project.  But even MS documentation states that it
> doesn't always work.
>
>
> https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
> This says you should be able to open the proper development window and use
> Ninja.
>
> The output shows that in the environment you are using it doesn't even
> know how to use cl.exe to even determine with compiler it is.  Maybe not
> all the proper environment variables and paths are being set correctly when
> using the compiler.
>
> --
> F
>
> On Tue, Sep 17, 2019, at 3:11 PM, Joao Pedro Abreu De Souza wrote:
>
> Thanks, I'll check it out.
>
> The toolchain file, as is, can generate ninja builds that can be used to
> generate a executable, but when I execute them, he say :
>
> ```
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/bin/amd64_x86/cl.exe
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
> Studio 12.0/VC/bin/amd64_x86/cl.exe -- broken
> CMake Error at C:/Program
> Files/CMake/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):
>   The C compiler
>
> "C:/Program Files (x86)/Microsoft Visual Studio
> 12.0/VC/bin/amd64_x86/cl.exe"
>
>   is not able to compile a simple test program.
>
>   It fails with the following output:
>
> Change Dir:
> C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp
>
> Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe
> cmTC_0dfb4 && [1/2] Building C object
> CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj
> FAILED: CMakeFiles/cmTC_0dfb4.dir/testCCompiler.c.obj
> "C:\PROGRA~2\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\cl.exe"
>  -o CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj   -c testCCompiler.c
> ninja: build stopped: subcommand failed.
>
>
>
>
>
>   CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>   CMakeLists.txt:2 (project)
> ```
>
> Em ter, 17 de set de 2019 às 16:02, Juan Sanchez 
> escreveu:
>
> From my brief research, it looks like the Microsoft version of CMake may
> have Ninja support.
>
>
> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/
>
>
> Regards,
>
> Juan
>
> On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <
> jp_ab...@id.uff.br> wrote:
>
> So, only the Visual Studio generator use the Arch option? I try generate
> ninja build, but cmake(3.15.3) and the answer was
>
> ```
> $ cmake -B build -S . -G "Ninja" -A Win32
> CMake Error at CMakeLists.txt:2 (project):
>   Generator
>
> Ninja
>
>   does not support platform specification, but platform
>
> Win32
>
>   was specified.
>
>
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> See also
> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
> ```
>
> Em ter, 17 de set de 2019 às 14:00, Juan Sanchez 
> escreveu:
>
> Hello,
>
> My impression that targeting 32 bit depends on what generator you are
> using.
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>
> It looks like cmake now has:
>
>- cmake -G "Visual Studio 15 2017" -A Win32
>- cmake -G "Visual Studio 15 2017" -A x64
>
> It used to be that the default target platform was Win32, and  you had to
> specify Win64 in the generator string to target a 64 bit build.  For
> example with Visual Studio 2015
>
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>
> For compatibility with CMake versions prior to 3.1, one may specify a
> target platform name optionally at the end of the generator name. This is
> supported on

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[fdk17]

As I recall for myself, simply using the Visual Studio Generator with the -A 
option was all that was needed to build for Win32.
You don't need a toolchain file because the generator already knows how to 
setup a Visual Studio Project to target Win32.
Even the documentation for cross-compiling doesn't show a need to setup 
toolchain file for cross compiling in this case.

I personally never seen anyone try to use the Ninja generator via command line 
CMake and use the cl.exe compiler.
I've only seen that using Visual Studio to open a CMakeLists.txt file it can 
produce a Ninja project. But even MS documentation states that it doesn't 
always work.

https://stackoverflow.com/questions/31262342/cmake-g-ninja-on-windows-specify-x64
This says you should be able to open the proper development window and use 
Ninja.

The output shows that in the environment you are using it doesn't even know how 
to use cl.exe to even determine with compiler it is. Maybe not all the proper 
environment variables and paths are being set correctly when using the compiler.

--
F

On Tue, Sep 17, 2019, at 3:11 PM, Joao Pedro Abreu De Souza wrote:
> Thanks, I'll check it out.
> 
> The toolchain file, as is, can generate ninja builds that can be used to 
> generate a executable, but when I execute them, he say : 
> 
> ```
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual 
> Studio 12.0/VC/bin/amd64_x86/cl.exe
> -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual 
> Studio 12.0/VC/bin/amd64_x86/cl.exe -- broken
> CMake Error at C:/Program 
> Files/CMake/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):
>  The C compiler
> 
>  "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/bin/amd64_x86/cl.exe"
> 
>  is not able to compile a simple test program.
> 
>  It fails with the following output:
> 
>  Change Dir: 
> C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp
> 
>  Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_0dfb4 && 
> [1/2] Building C object CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj
>  FAILED: CMakeFiles/cmTC_0dfb4.dir/testCCompiler.c.obj
>  "C:\PROGRA~2\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\cl.exe" -o 
> CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj -c testCCompiler.c
>  ninja: build stopped: subcommand failed.
> 
> 
> 
> 
> 
>  CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>  CMakeLists.txt:2 (project)
> ```
> 
> Em ter, 17 de set de 2019 às 16:02, Juan Sanchez  
> escreveu:
>> From my brief research, it looks like the Microsoft version of CMake may 
>> have Ninja support.
>> 
>> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/
>>  
>> 
>> Regards,
>> 
>> Juan
>> 
>> On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza 
>>  wrote:
>>> So, only the Visual Studio generator use the Arch option? I try generate 
>>> ninja build, but cmake(3.15.3) and the answer was 
>>> 
>>> ```
>>> $ cmake -B build -S . -G "Ninja" -A Win32
>>> CMake Error at CMakeLists.txt:2 (project):
>>>  Generator
>>> 
>>>  Ninja
>>> 
>>>  does not support platform specification, but platform
>>> 
>>>  Win32
>>> 
>>>  was specified.
>>> 
>>> 
>>> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
>>> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
>>> -- Configuring incomplete, errors occurred!
>>> See also 
>>> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
>>> ```
>>> 
>>> Em ter, 17 de set de 2019 às 14:00, Juan Sanchez  
>>> escreveu:
 Hello,
 
 My impression that targeting 32 bit depends on what generator you are 
 using.
 https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
 
 It looks like cmake now has:
  * `cmake -G "Visual Studio 15 2017" -A Win32`
  * `cmake -G "Visual Studio 15 2017" -A x64`
 It used to be that the default target platform was Win32, and you had to 
 specify Win64 in the generator string to target a 64 bit build. For 
 example with Visual Studio 2015
 
 https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
 
 For compatibility with CMake versions prior to 3.1, one may specify a 
 target platform name optionally at the end of the generator name. This is 
 supported only for:

 `Visual Studio 14 2015 Win64`
 Specify target platform `x64`.
 `Visual Studio 14 2015 ARM`
 Specify target platform `ARM`.
 
 
 Regards,
 
 Juan
 
 
 On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza 
  wrote:
> cl from visual studio 2017.
> 
> Em ter, 17 de set de 2019 03:26, Stéphane Ancelot 
>  escreveu:
>> Hi,

>> That first depends on which compiler you will use ?

>> Regards,

>

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

Thanks, I'll check it out.

The toolchain file, as is, can generate ninja builds that can be used to
generate a executable, but when I execute them, he say :

```
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/amd64_x86/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio 12.0/VC/bin/amd64_x86/cl.exe -- broken
CMake Error at C:/Program
Files/CMake/share/cmake-3.15/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

"C:/Program Files (x86)/Microsoft Visual Studio
12.0/VC/bin/amd64_x86/cl.exe"

  is not able to compile a simple test program.

  It fails with the following output:

Change Dir:
C:/Users/jpabreu/Desktop/testCMAKE/build_Win32_normal/CMakeFiles/CMakeTmp

Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_0dfb4
&& [1/2] Building C object CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj
FAILED: CMakeFiles/cmTC_0dfb4.dir/testCCompiler.c.obj
"C:\PROGRA~2\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\cl.exe"
 -o CMakeFiles\cmTC_0dfb4.dir\testCCompiler.c.obj   -c testCCompiler.c
ninja: build stopped: subcommand failed.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)
```

Em ter, 17 de set de 2019 às 16:02, Juan Sanchez 
escreveu:

> From my brief research, it looks like the Microsoft version of CMake may
> have Ninja support.
>
>
> https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/
>
>
> Regards,
>
> Juan
>
> On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <
> jp_ab...@id.uff.br> wrote:
>
>> So, only the Visual Studio generator use the Arch option? I try generate
>> ninja build, but cmake(3.15.3) and the answer was
>>
>> ```
>> $ cmake -B build -S . -G "Ninja" -A Win32
>> CMake Error at CMakeLists.txt:2 (project):
>>   Generator
>>
>> Ninja
>>
>>   does not support platform specification, but platform
>>
>> Win32
>>
>>   was specified.
>>
>>
>> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
>> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
>> -- Configuring incomplete, errors occurred!
>> See also
>> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
>> ```
>>
>> Em ter, 17 de set de 2019 às 14:00, Juan Sanchez <
>> juan.e.sanc...@gmail.com> escreveu:
>>
>>> Hello,
>>>
>>> My impression that targeting 32 bit depends on what generator you are
>>> using.
>>>
>>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>>>
>>> It looks like cmake now has:
>>>
>>>- cmake -G "Visual Studio 15 2017" -A Win32
>>>- cmake -G "Visual Studio 15 2017" -A x64
>>>
>>> It used to be that the default target platform was Win32, and  you had
>>> to specify Win64 in the generator string to target a 64 bit build.  For
>>> example with Visual Studio 2015
>>>
>>>
>>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>>>
>>> For compatibility with CMake versions prior to 3.1, one may specify a
>>> target platform name optionally at the end of the generator name. This is
>>> supported only for:
>>> Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14
>>> 2015 ARMSpecify target platform ARM.
>>>
>>>
>>> Regards,
>>>
>>> Juan
>>>
>>>
>>> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
>>> jp_ab...@id.uff.br> wrote:
>>>
 cl from visual studio 2017.

 Em ter, 17 de set de 2019 03:26, Stéphane Ancelot <
 sance...@numalliance.com> escreveu:

> Hi,
>
> That first depends on which compiler you will use ?
>
> Regards,
>
> S.Ancelot
> Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
>
> Hi guys. I am trying to generate,using cmake, a executable with target
> Windows 32 bits using Windows 64 bits, but cannot find a standard 
> toolchain
> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
> build. Do you know some repository of toolchain files that has Windows 32
> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
> to this type of thing.
>
> Thanks in advance.
>
> --

 Powered by www.kitware.com

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ

 Kitware offers various services to support the CMake community. For
 more information on each offering, please visit:

 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html

 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html

 Follow this link to su

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Juan Sanchez]

>From my brief research, it looks like the Microsoft version of CMake may
have Ninja support.

https://devblogs.microsoft.com/cppblog/cmake-support-in-visual-studio-whats-new-in-2017-15-3-update/


Regards,

Juan

On Tue, Sep 17, 2019 at 1:36 PM Joao Pedro Abreu De Souza <
jp_ab...@id.uff.br> wrote:

> So, only the Visual Studio generator use the Arch option? I try generate
> ninja build, but cmake(3.15.3) and the answer was
>
> ```
> $ cmake -B build -S . -G "Ninja" -A Win32
> CMake Error at CMakeLists.txt:2 (project):
>   Generator
>
> Ninja
>
>   does not support platform specification, but platform
>
> Win32
>
>   was specified.
>
>
> CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
> CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
> -- Configuring incomplete, errors occurred!
> See also
> "C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
> ```
>
> Em ter, 17 de set de 2019 às 14:00, Juan Sanchez 
> escreveu:
>
>> Hello,
>>
>> My impression that targeting 32 bit depends on what generator you are
>> using.
>>
>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>>
>> It looks like cmake now has:
>>
>>- cmake -G "Visual Studio 15 2017" -A Win32
>>- cmake -G "Visual Studio 15 2017" -A x64
>>
>> It used to be that the default target platform was Win32, and  you had to
>> specify Win64 in the generator string to target a 64 bit build.  For
>> example with Visual Studio 2015
>>
>>
>> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>>
>> For compatibility with CMake versions prior to 3.1, one may specify a
>> target platform name optionally at the end of the generator name. This is
>> supported only for:
>> Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14
>> 2015 ARMSpecify target platform ARM.
>>
>>
>> Regards,
>>
>> Juan
>>
>>
>> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
>> jp_ab...@id.uff.br> wrote:
>>
>>> cl from visual studio 2017.
>>>
>>> Em ter, 17 de set de 2019 03:26, Stéphane Ancelot <
>>> sance...@numalliance.com> escreveu:
>>>
 Hi,

 That first depends on which compiler you will use ?

 Regards,

 S.Ancelot
 Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :

 Hi guys. I am trying to generate,using cmake, a executable with target
 Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
 file (I find to Linux, to Android, but can't find to Windows 32 bits) to
 build. Do you know some repository of toolchain files that has Windows 32
 bits from Windows 64 bits? Or maybe someone has a standard toolchain file
 to this type of thing.

 Thanks in advance.

 --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake
>>>
>>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

So, only the Visual Studio generator use the Arch option? I try generate
ninja build, but cmake(3.15.3) and the answer was

```
$ cmake -B build -S . -G "Ninja" -A Win32
CMake Error at CMakeLists.txt:2 (project):
  Generator

Ninja

  does not support platform specification, but platform

Win32

  was specified.


CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also
"C:/Users/jpabreu/Desktop/testCMAKE/build/CMakeFiles/CMakeOutput.log".
```

Em ter, 17 de set de 2019 às 14:00, Juan Sanchez 
escreveu:

> Hello,
>
> My impression that targeting 32 bit depends on what generator you are
> using.
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html
>
> It looks like cmake now has:
>
>- cmake -G "Visual Studio 15 2017" -A Win32
>- cmake -G "Visual Studio 15 2017" -A x64
>
> It used to be that the default target platform was Win32, and  you had to
> specify Win64 in the generator string to target a 64 bit build.  For
> example with Visual Studio 2015
>
>
> https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html
>
> For compatibility with CMake versions prior to 3.1, one may specify a
> target platform name optionally at the end of the generator name. This is
> supported only for:
> Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14
> 2015 ARMSpecify target platform ARM.
>
>
> Regards,
>
> Juan
>
>
> On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
> jp_ab...@id.uff.br> wrote:
>
>> cl from visual studio 2017.
>>
>> Em ter, 17 de set de 2019 03:26, Stéphane Ancelot <
>> sance...@numalliance.com> escreveu:
>>
>>> Hi,
>>>
>>> That first depends on which compiler you will use ?
>>>
>>> Regards,
>>>
>>> S.Ancelot
>>> Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
>>>
>>> Hi guys. I am trying to generate,using cmake, a executable with target
>>> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
>>> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
>>> build. Do you know some repository of toolchain files that has Windows 32
>>> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
>>> to this type of thing.
>>>
>>> Thanks in advance.
>>>
>>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Guy Mac]

AFAIK you can set the generator in a CMakeSettings.json file if you are 
using MSVC.


https://docs.microsoft.com/en-us/cpp/build/cmakesettings-reference?view=vs-2019

On 9/17/2019 10:00 AM, Juan Sanchez wrote:

Hello,

My impression that targeting 32 bit depends on what generator you are 
using.

https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html

It looks like cmake now has:

  * |cmake -G "Visual Studio 15 2017" -A Win32|
  * |cmake -G "Visual Studio 15 2017" -A x64|

It used to be that the default target platform was Win32, and  you had 
to specify Win64 in the generator string to target a 64 bit build.  
For example with Visual Studio 2015


https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html

For compatibility with CMake versions prior to 3.1, one may specify a 
target platform name optionally at the end of the generator name. This 
is supported only for:


|Visual Studio 14 2015 Win64|
Specify target platform |x64|.
|Visual Studio 14 2015 ARM|
Specify target platform |ARM|.



Regards,

Juan


On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza 
mailto:jp_ab...@id.uff.br>> wrote:


cl from visual studio 2017.

Em ter, 17 de set de 2019 03:26, Stéphane Ancelot
mailto:sance...@numalliance.com>> escreveu:

Hi,

That first depends on which compiler you will use ?

Regards,

S.Ancelot

Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :

Hi guys. I am trying to generate,using cmake, a executable
with target Windows 32 bits using Windows 64 bits, but cannot
find a standard toolchain file (I find to Linux, to Android,
but can't find to Windows 32 bits) to build. Do you know some
repository of toolchain files that has Windows 32 bits from
Windows 64 bits? Or maybe someone has a standard toolchain
file to this type of thing.

Thanks in advance.

-- 


Powered by www.kitware.com 

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community.
For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Juan Sanchez]

Hello,

My impression that targeting 32 bit depends on what generator you are using.
https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2015%202017.html

It looks like cmake now has:

   - cmake -G "Visual Studio 15 2017" -A Win32
   - cmake -G "Visual Studio 15 2017" -A x64

It used to be that the default target platform was Win32, and  you had to
specify Win64 in the generator string to target a 64 bit build.  For
example with Visual Studio 2015

https://cmake.org/cmake/help/git-stage/generator/Visual%20Studio%2014%202015.html

For compatibility with CMake versions prior to 3.1, one may specify a
target platform name optionally at the end of the generator name. This is
supported only for:
Visual Studio 14 2015 Win64Specify target platform x64.Visual Studio 14 2015
 ARMSpecify target platform ARM.


Regards,

Juan


On Tue, Sep 17, 2019 at 7:18 AM Joao Pedro Abreu De Souza <
jp_ab...@id.uff.br> wrote:

> cl from visual studio 2017.
>
> Em ter, 17 de set de 2019 03:26, Stéphane Ancelot <
> sance...@numalliance.com> escreveu:
>
>> Hi,
>>
>> That first depends on which compiler you will use ?
>>
>> Regards,
>>
>> S.Ancelot
>> Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
>>
>> Hi guys. I am trying to generate,using cmake, a executable with target
>> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
>> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
>> build. Do you know some repository of toolchain files that has Windows 32
>> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
>> to this type of thing.
>>
>> Thanks in advance.
>>
>> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Albrecht Schlosser]

On 9/17/19 2:17 PM Joao Pedro Abreu De Souza wrote:

cl from visual studio 2017.

Em ter, 17 de set de 2019 03:26, Stéphane Ancelot 
mailto:sance...@numalliance.com>> escreveu:


Hi,

That first depends on which compiler you will use ?

Regards,

S.Ancelot

Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :

Hi guys. I am trying to generate,using cmake, a executable with
target Windows 32 bits using Windows 64 bits, but cannot find a
standard toolchain file (I find to Linux, to Android, but can't
find to Windows 32 bits) to build. Do you know some repository of
toolchain files that has Windows 32 bits from Windows 64 bits? Or
maybe someone has a standard toolchain file to this type of thing.


Well, I don't have a toolchain file for your compiler, but maybe my 
toolchain file for cross compilation under Linux for Windows (64-bit) 
can help. You'll need to adjust compiler and paths...


$ cat mingw-w64_toolchain.cmake
# CMake Toolchain File for MinGW-w64 (64-bit) Cross Compilation

# the name of the target operating system
set(CMAKE_SYSTEM_NAME Windows)

# which tools to use
set(CMAKE_C_COMPILER   /usr/bin/x86_64-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER /usr/bin/x86_64-w64-mingw32-g++)

# here is where the target environment located
set(CMAKE_FIND_ROOT_PATH  /usr/x86_64-w64-mingw32)

# adjust the default behavior of the FIND_XXX() commands:

# search programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

# search headers and libraries in the target environment
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

set(CMAKE_INSTALL_PREFIX ${CMAKE_FIND_ROOT_PATH}/usr CACHE FILEPATH
   "install path prefix")

# initialize required linker flags
set(CMAKE_EXE_LINKER_FLAGS_INIT "-static-libgcc -static-libstdc++")

# end of toolchain file

HTH. YMMV
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

cl from visual studio 2017.

Em ter, 17 de set de 2019 03:26, Stéphane Ancelot 
escreveu:

> Hi,
>
> That first depends on which compiler you will use ?
>
> Regards,
>
> S.Ancelot
> Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
>
> Hi guys. I am trying to generate,using cmake, a executable with target
> Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
> file (I find to Linux, to Android, but can't find to Windows 32 bits) to
> build. Do you know some repository of toolchain files that has Windows 32
> bits from Windows 64 bits? Or maybe someone has a standard toolchain file
> to this type of thing.
>
> Thanks in advance.
>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Stéphane Ancelot]

Hi,

That first depends on which compiler you will use ?

Regards,

S.Ancelot

Le 16/09/2019 à 22:32, Joao Pedro Abreu De Souza a écrit :
Hi guys. I am trying to generate,using cmake, a executable with target 
Windows 32 bits using Windows 64 bits, but cannot find a standard 
toolchain file (I find to Linux, to Android, but can't find to Windows 
32 bits) to build. Do you know some repository of toolchain files that 
has Windows 32 bits from Windows 64 bits? Or maybe someone has a 
standard toolchain file to this type of thing.


Thanks in advance.

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] toolchain file - cross-compiling windows-amd64->windows-x86

[Joao Pedro Abreu De Souza]

Hi guys. I am trying to generate,using cmake, a executable with target
Windows 32 bits using Windows 64 bits, but cannot find a standard toolchain
file (I find to Linux, to Android, but can't find to Windows 32 bits) to
build. Do you know some repository of toolchain files that has Windows 32
bits from Windows 64 bits? Or maybe someone has a standard toolchain file
to this type of thing.

Thanks in advance.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file for TI in CMake 3.10: how do I override compiler options and specify tools?

[frodak17]

On Sat, Feb 23, 2019 at 2:24 PM Cristian Adam 
wrote:

>
>
> On Sat, Feb 23, 2019 at 8:49 AM Jason Heeris 
> wrote:
>
>> I am trying to use CMake (3.10) to build an ANSI C project that may be
>> compiled on PC with eg. GCC, but also needs to compile with Texas
>> Instruments' compilers for their microprocessors. So I have about a million
>> questions.
>>
>> According to[1] it seems like the way to do this is via a toolchain file.
>> So I'm trying to write a toolchain file to use TI's compiler/linker/etc,
>> which do not (always) take the same arguments as eg. GCC or Clang.
>>
>> Is there a complete list of tools I can override in a toolchain file?
>> Specifically, I want to set the C compiler, C++ compiler, assembler and
>> linker. I know about CMAKE_C(XX)_COMPILER, but what about the others? Are
>> they documented anywhere? (I could guess, but I don't think that's wise.)
>>
>> As I mentioned, TI's tools aren't the same as GCC, so I need to pare back
>> a lot of options and start from almost-scratch (there are some
>> commonalities). Options like "-D" and "-I" are fine, which is good because
>> then eg. target_include_directories() still works. But certain other flags
>> are just going to cause errors. How do I completely remove all compile
>> flags from the generated Makefiles and replace them with my own? I can do
>> this:
>>
>> set(CMAKE_C_FLAGS ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>> set(CMAKE_C_FLAGS_DEBUG ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>> set(CMAKE_C_FLAGS_RELEASE ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>> set(CMAKE_C_FLAGS_RELWITHDEBINFO ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>> set(CMAKE_C_FLAGS_MINSIZEREL ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>>
>> But I *still* see flags in the generated makefiles that I didn't put
>> there such as "--compile_only" and "--c_file=...". How do I get rid of
>> these and specify what's correct for my toolchain? (Also, why do I need the
>> CACHE STRING "" FORCE options? I pulled that out of various Stackoverflow
>> posts but I have no idea why it's necessary. Is that documented? What about
>> the configurations... where are they listed? Do I have them all?)
>>
>>
> Regarding the CMAKE__FLAGS_ have a look at this blog post:
> https://cristianadam.eu/20190223/modifying-the-default-cmake-build-types/
>
> You "just" need to modify the CMAKE__FLAGS__INIT variables,
> no need to force the cache entries.
>
> The "Modules" CMake folder is your friend, you can see how CMake handles
> other compilers.
> For debugging use CMake's "--trace-expand" command line parameter.
>
> Cheers,
> Cristian.
>
>
Take a look at Modules/CMakeCInformation.cmake.
Also CMAKE_USER_MAKE_RULES_OVERRIDE may be useful to you.
There are a few others that may also be used depending on what languages
you are trying to use.

StackOverflow isn't always correct even if something is marked as answered
and up-voted.

FYI, The "--compile_only" and "--c_file" probably come from the file
Modules/Compiler/TI-C.cmake.  At some point TI compilers were using those
options to build files but I guess in your case the compiler is no longer
compatible with what it used to be.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file for TI in CMake 3.10: how do I override compiler options and specify tools?

[Cristian Adam]

On Sat, Feb 23, 2019 at 8:49 AM Jason Heeris  wrote:

> I am trying to use CMake (3.10) to build an ANSI C project that may be
> compiled on PC with eg. GCC, but also needs to compile with Texas
> Instruments' compilers for their microprocessors. So I have about a million
> questions.
>
> According to[1] it seems like the way to do this is via a toolchain file.
> So I'm trying to write a toolchain file to use TI's compiler/linker/etc,
> which do not (always) take the same arguments as eg. GCC or Clang.
>
> Is there a complete list of tools I can override in a toolchain file?
> Specifically, I want to set the C compiler, C++ compiler, assembler and
> linker. I know about CMAKE_C(XX)_COMPILER, but what about the others? Are
> they documented anywhere? (I could guess, but I don't think that's wise.)
>
> As I mentioned, TI's tools aren't the same as GCC, so I need to pare back
> a lot of options and start from almost-scratch (there are some
> commonalities). Options like "-D" and "-I" are fine, which is good because
> then eg. target_include_directories() still works. But certain other flags
> are just going to cause errors. How do I completely remove all compile
> flags from the generated Makefiles and replace them with my own? I can do
> this:
>
> set(CMAKE_C_FLAGS ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_DEBUG ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_RELEASE ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_RELWITHDEBINFO ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_MINSIZEREL ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>
> But I *still* see flags in the generated makefiles that I didn't put there
> such as "--compile_only" and "--c_file=...". How do I get rid of these and
> specify what's correct for my toolchain? (Also, why do I need the CACHE
> STRING "" FORCE options? I pulled that out of various Stackoverflow posts
> but I have no idea why it's necessary. Is that documented? What about the
> configurations... where are they listed? Do I have them all?)
>
>
Regarding the CMAKE__FLAGS_ have a look at this blog post:
https://cristianadam.eu/20190223/modifying-the-default-cmake-build-types/

You "just" need to modify the CMAKE__FLAGS__INIT variables,
no need to force the cache entries.

The "Modules" CMake folder is your friend, you can see how CMake handles
other compilers.
For debugging use CMake's "--trace-expand" command line parameter.

Cheers,
Cristian.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file for TI in CMake 3.10: how do I override compiler options and specify tools?

[Patrick Griffiths]

On Sat, Feb 23, 2019 at 12:49 AM Jason Heeris 
wrote:

> I am trying to use CMake (3.10) to build an ANSI C project that may be
> compiled on PC with eg. GCC, but also needs to compile with Texas
> Instruments' compilers for their microprocessors. So I have about a million
> questions.
>
> According to[1] it seems like the way to do this is via a toolchain file.
> So I'm trying to write a toolchain file to use TI's compiler/linker/etc,
> which do not (always) take the same arguments as eg. GCC or Clang.
>
> Is there a complete list of tools I can override in a toolchain file?
> Specifically, I want to set the C compiler, C++ compiler, assembler and
> linker. I know about CMAKE_C(XX)_COMPILER, but what about the others? Are
> they documented anywhere? (I could guess, but I don't think that's wise.)
>
> As I mentioned, TI's tools aren't the same as GCC, so I need to pare back
> a lot of options and start from almost-scratch (there are some
> commonalities). Options like "-D" and "-I" are fine, which is good because
> then eg. target_include_directories() still works. But certain other flags
> are just going to cause errors. How do I completely remove all compile
> flags from the generated Makefiles and replace them with my own? I can do
> this:
>
> set(CMAKE_C_FLAGS ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_DEBUG ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_RELEASE ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_RELWITHDEBINFO ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
> set(CMAKE_C_FLAGS_MINSIZEREL ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
>
> But I *still* see flags in the generated makefiles that I didn't put there
> such as "--compile_only" and "--c_file=...". How do I get rid of these and
> specify what's correct for my toolchain? (Also, why do I need the CACHE
> STRING "" FORCE options? I pulled that out of various Stackoverflow posts
> but I have no idea why it's necessary. Is that documented? What about the
> configurations... where are they listed? Do I have them all?)
>
> (I keep asking "is this documented anywhere" because I like to provide
> references in code for future maintainers. I'm not trying to be unkind.
> Maybe once I know enough I can volunteer to write any missing docs myself.)
>
> How do I add default flags that involve the source file name eg. for a
> file "main.c" I want to have a C compiler flag "--some_option='main.x'"?
>
> Finally, this really seems like a lot of work despite the fact that
> toolchain files are (I thought) meant to be the way to define a different
> toolchain. It really feels like I'm swimming against the tide here. Is
> there another, more-CMake-ish way to accomplish what I'm trying to do?
>
> [1]
> https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling
>
> Thanks for any help.
>
> - Jason
> --
>
>

I've written toolchain files for cross-compiling with gcc and/or clang, but
not for for proprietary compilers, but maybe this brain dump can help:

In addition to CMAKE__COMPILER, you'll probably need to look at:

CMAKE__FLAGS_INIT
CMAKE__FLAGS_DEBUG_INIT
etc ...

Sounds like you need to set them all explicitly since CMake doesn't know
anything about your toolchain out of the box. The configurations (debug,
release, etc) are handled by the variable naming. You should be able to set
exactly what you want.  CMake glues the various flag variables together so
you might need to experiment a little to see what the result is.

You might want to look at the CMAKE_TRY_COMPILE_* variable as it sounds
like you're compiling for baremetal or an RTOS.

Unfortunately, I think you're best best is  to dig through the
documentation and trial and error. The variables and toolchain sections
will be helpful:

https://cmake.org/cmake/help/v3.10/index.html

cmake has command line options you might find useful like --trace and
--debug-trycompile.

You can do make VERBOSE=1 to see what's executed.

FWIW, I suggest starting with a single .c file with an empty main. Once
that compiles, start adding complexity. Good luck.

HTH
Patrick
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Toolchain file for TI in CMake 3.10: how do I override compiler options and specify tools?

[Jason Heeris]

I am trying to use CMake (3.10) to build an ANSI C project that may be
compiled on PC with eg. GCC, but also needs to compile with Texas
Instruments' compilers for their microprocessors. So I have about a million
questions.

According to[1] it seems like the way to do this is via a toolchain file.
So I'm trying to write a toolchain file to use TI's compiler/linker/etc,
which do not (always) take the same arguments as eg. GCC or Clang.

Is there a complete list of tools I can override in a toolchain file?
Specifically, I want to set the C compiler, C++ compiler, assembler and
linker. I know about CMAKE_C(XX)_COMPILER, but what about the others? Are
they documented anywhere? (I could guess, but I don't think that's wise.)

As I mentioned, TI's tools aren't the same as GCC, so I need to pare back a
lot of options and start from almost-scratch (there are some
commonalities). Options like "-D" and "-I" are fine, which is good because
then eg. target_include_directories() still works. But certain other flags
are just going to cause errors. How do I completely remove all compile
flags from the generated Makefiles and replace them with my own? I can do
this:

set(CMAKE_C_FLAGS ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_DEBUG ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELEASE ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_RELWITHDEBINFO ${MINIMAL_FLAGS} CACHE STRING "" FORCE)
set(CMAKE_C_FLAGS_MINSIZEREL ${MINIMAL_FLAGS} CACHE STRING "" FORCE)

But I *still* see flags in the generated makefiles that I didn't put there
such as "--compile_only" and "--c_file=...". How do I get rid of these and
specify what's correct for my toolchain? (Also, why do I need the CACHE
STRING "" FORCE options? I pulled that out of various Stackoverflow posts
but I have no idea why it's necessary. Is that documented? What about the
configurations... where are they listed? Do I have them all?)

(I keep asking "is this documented anywhere" because I like to provide
references in code for future maintainers. I'm not trying to be unkind.
Maybe once I know enough I can volunteer to write any missing docs myself.)

How do I add default flags that involve the source file name eg. for a file
"main.c" I want to have a C compiler flag "--some_option='main.x'"?

Finally, this really seems like a lot of work despite the fact that
toolchain files are (I thought) meant to be the way to define a different
toolchain. It really feels like I'm swimming against the tide here. Is
there another, more-CMake-ish way to accomplish what I'm trying to do?

[1]
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/CrossCompiling

Thanks for any help.

- Jason
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] toolchain

[Stéphane Ancelot]

Hi,

My project needs being compiled for different targets : win32 (linux 
mingw32) / linux64 (Opensuse 13.2) / linux32 (Ubuntu 10.04)


using toolchain is the right option isn't it ???

some people told me it was deprecated ?

Regards,

S.Ancelot

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Toolchain files and vcpkg

[Máté Ferenc Nagy-Egri via CMake]

Hi!

I’m trying to use packages (HPX specifically) installed with vcpkg, and 
according to its wiki, it is easiest to do so via the toolchain file provided 
by vcpkg.

Here’s is what I’m doing:

cd build
cmake -G „Ninja” -D CMAKE_BUILD_TYPE=Release -D 
CMAKE_TOOLCHAIN_FILE=C:/Users/nagy-/Source/Repos/vcpkg/scripts/buildsystems/vcpkg.cmake
 ..\

But it seems that CMake completely disregards the toolchain file, as if it 
weren’t even there. Same happens for Visual Studio generators, not just Ninja. 
Am I doing something wrong? Does anyone have a minimal working script with HPX 
installed through vcpkg?

Cheers,
Máté
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Toolchain with non-gcc argument format

[oliver . zabel]

Hi,

Sorry - I don’t get the hint :) thanks, I will look into it!

Cheers!
Oliver
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Toolchain with non-gcc argument format

[Konstantin Tokarev]

14.11.2017, 15:32, "oliver.za...@egoproducts.com" 
:
> Hi,
>
> Thank you. There is unfortunately not the right toolchain there - according
> my question I do have my toolchain Running - but with a custom command and
> I would like to know whether there is a better way.

I meant you can use this files as an example and make correct file for your 
toolchain.

E.g. see how TI-C.cmake sets CMAKE_INCLUDE_FLAG_C

>
> Cheers!

-- 
Regards,
Konstantin
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Toolchain with non-gcc argument format

[oliver . zabel]

Hi,

Thank you. There is unfortunately not the right toolchain there - according
my question I do have my toolchain Running - but with a custom command and
I would like to know whether there is a better way.

Cheers!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Toolchain with non-gcc argument format

[Konstantin Tokarev]

14.11.2017, 12:37, "oliver.za...@egoproducts.com" 
:
> Hi,
>
> No one any idea?

Look into Modules/Compiler directory of CMake installation, it implements 
support for many different compilers

>
> Thanks!
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 
Regards,
Konstantin
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Toolchain with non-gcc argument format

[oliver . zabel]

Hi,

No one any idea?

Thanks!

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Toolchain with non-gcc argument format

[oliver . zabel]

Hi, 

i have some modules which i want to cross-compile for different platforms 
which uses different compilers. One of them for example is the arm-gcc 
compiler which works over the toolchain file. 
Now i have a Renesas RX compiler which uses for example instead of "-I" 
for include paths the argument "-include=". So using this toolchain fails 
because cmake trys to use gcc arguments.

I managed to compile my modules with the following approache:

set(CMAKE_C_COMPILER_WORKS 1)
project(MyModule C)
cmake_minimum_required(VERSION 3.0)

set(EXECUTABLE_NAME MyModule)
set(SRC_FILES
${PROJECT_SOURCE_DIR}/module.c
${PROJECT_SOURCE_DIR}/main.c
)

IF(RXCOMPILER)
  MESSAGE(STATUS "RX Mode")
  add_custom_target(dummy_target ALL DEPENDS EXECUTABLE_NAME)
 
  ADD_CUSTOM_COMMAND( 
OUTPUTEXECUTABLE_NAME
COMMAND   ${CMAKE_C_COMPILER}
ARGS  -output=obj=abs -cpu=rx200 -lang=c99 -goptimize -size 
${SRC_FILES}
COMMENT   "RX Compiler"
  )
ELSE(RXCOMPILER)

add_executable(EXECUTABLE_NAME ${SRC_FILES})
 
ENDIF(RXCOMPILER)

Is there a better way of doing this? For example telling cmake to use 
"-include=" instaed of "-I"?

Thanks for your help!

Best regards, 
oliver-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Toolchain rpath libraries

[Roman Savchenko]

Dear all,

I created toolchain file:

set(CMAKE_SYSTEM_NAME Linux)

set(CMAKE_SYSROOT "/srv/chroots/centos6-amd64")

set(CMAKE_C_FLAGS   "-gcc-name=${CMAKE_SYSROOT}/usr/bin/gcc
-L${CMAKE_SYSROOT}/usr/lib64")
set(CMAKE_CXX_FLAGS "-gxx-name=${CMAKE_SYSROOT}/usr/bin/g++
-L${CMAKE_SYSROOT}/usr/lib64")

set(CMAKE_C_COMPILER   ${CMAKE_SYSROOT}/opt/intel/bin/icc  CACHE STRING "cc")
set(CMAKE_CXX_COMPILER ${CMAKE_SYSROOT}/opt/intel/bin/icpc CACHE STRING "cxx")
set(CMAKE_LINKER   ${CMAKE_SYSROOT}/usr/bin/ldCACHE STRING "ld")
set(CMAKE_AR${CMAKE_SYSROOT}/usr/bin/arCACHE STRING "ar")
set(CMAKE_NM${CMAKE_SYSROOT}/usr/bin/nm CACHE STRING "nm" )
set(CMAKE_OBJCOPY  ${CMAKE_SYSROOT}/usr/bin/objcopyCACHE
STRING "objcopy")
set(CMAKE_OBJDUMP  ${CMAKE_SYSROOT}/usr/bin/objdumpCACHE
STRING "objdump")
set(CMAKE_RANLIB   ${CMAKE_SYSROOT}/usr/bin/ranlib CACHE
STRING "ranlib")
set(CMAKE_STRIP${CMAKE_SYSROOT}/usr/bin/strip  CACHE STRING "strip")

set(CMAKE_SKIP_RPATH TRUE)

set(CMAKE_FIND_ROOT_PATH "${CMAKE_SYSROOT}")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

But there is a broblem with compilation - wrong path to libraries:

/usr/bin/cmake -E cmake_link_script CMakeFiles/Test.dir/link.txt --verbose=1
/srv/chroots/centos6-amd64/opt/intel/bin/icpc-std=c++11 -Wall
-ggdb -O0   CMakeFiles/Test.dir/main.cpp.o
CMakeFiles/TestBed.dir/test.cpp.o  -o Test
-L/srv/chroots/centos6-amd64/usr/lib64 -lrt -lnuma -lzlib
-Wl,-rpath,/usr/lib64

ld: cannot find /lib64/libc.so.6
ld: cannot find /usr/lib64/libc_nonshared.a


This libraries exist under:
${CMAKE_SYSROOT}/lib64

So how can I tell toolchain to look up there?

Many thanls,
R. Savchenko
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] CMAKE toolchain file for TI armcl compiler

[R, Manoj]

Hi,

I have been trying to build toolchain file for armcl compiler from TI.Attached 
is the the cmake toolchain file and makefile.
I am not able to get my link step  working even after trying changing options 
for like 2 days.Can you please help me analyse where I am going wrong.

Regards

[https://newoldstamp.com/editor/profilePictures/profile-aafdb6328626d8cd600d5eada210d956-161742.png]<http://www.ti.com/>

Manoj Rajashekaraiah   Software Engineer, MCU Software
Texas Instruments India Pvt Ltd
p: 918025193189 m: 918861001840
e: man...@ti.com<mailto:man...@ti.com>





Toolchain_ti-cgt-arm_5.2.7.cmake
Description: Toolchain_ti-cgt-arm_5.2.7.cmake


MakeFile
Description: MakeFile
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Toolchain file for VS2013 + November CTP compiler toolset?

[Robert Dailey]

On Fri, Jul 17, 2015 at 11:25 AM, Robert Dailey
 wrote:
> Hello,
>
> How would I define a toolchain file for the Visual Studio 2013
> generator that also defines the toolset for that generator to be the
> November CTP compiler?
>
> I'd rather use a toolchain for this than do -D definitions when I
> invoke cmake to generate.
>
> Thanks in advance.

Any thoughts on this? I'd actually rather specify the toolset within
my root CMakeLists.txt script (since when generating our code, you
*must* use the November CTP compiler when selecting the MSVC12
generator). However the documentation states it should not be set from
within the CMake script.

Ideas? The toolchain file is not necessary if it's valid to set the
CMAKE_GENERATOR_TOOLSET variable within the CMakeLists.txt script
(before or after the first project() call?)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] Toolchain file for VS2013 + November CTP compiler toolset?

[Robert Dailey]

Hello,

How would I define a toolchain file for the Visual Studio 2013
generator that also defines the toolset for that generator to be the
November CTP compiler?

I'd rather use a toolchain for this than do -D definitions when I
invoke cmake to generate.

Thanks in advance.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] CMake toolchain file for multiarch environment (Debian 8)

[Yegor Yefremov]

I'm trying to construct a suitable toolchain for CMake 3.0.2. I took
Buildroot's toochain.cmake and trying to tweak it:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR armv7l)

# specify the cross compiler
SET(CMAKE_C_COMPILER   "/usr/bin/arm-linux-gnueabihf-gcc")
SET(CMAKE_CXX_COMPILER "/usr/bin/arm-linux-gnueabihf-g++")

set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os ${CMAKE_C_FLAGS}" CACHE STRING "Buildroot
CFLAGS")
set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os ${CMAKE_CXX_FLAGS}" CACHE STRING "Buildroot
CXXFLAGS")
set(CMAKE_EXE_LINKER_FLAGS " ${CMAKE_EXE_LINKER_FLAGS}" CACHE STRING
"Buildroot LDFLAGS")
set(CMAKE_INSTALL_SO_NO_EXE 0)

set(CMAKE_PROGRAM_PATH "/usr/bin")
set(CMAKE_FIND_ROOT_PATH "/usr/lib/arm-linux-gnueabihf/cmake")
set(CMAKE_PREFIX_PATH "/usr/lib/arm-linux-gnueabihf/cmake")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(ENV{PKG_CONFIG_SYSROOT_DIR} "/usr/lib/arm-linux-gnueabihf/")

I have following problem with Qt5, i.e.Qt5WidgetsConfig.cmake will be
found with proper CMAKE_FIND_ROOT_PATH, but then something is missing
for CMake to work properly :

CMake Error at 
/usr/lib/arm-linux-gnueabihf/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:100
(find_package):
  Could not find a package configuration file provided by "Qt5Gui" (requested
  version 5.3.2) with any of the following names:

Qt5GuiConfig.cmake
qt5gui-config.cmake

  Add the installation prefix of "Qt5Gui" to CMAKE_PREFIX_PATH or set
  "Qt5Gui_DIR" to a directory containing one of the above files.  If "Qt5Gui"
  provides a separate development package or SDK, be sure it has been
  installed.
Call Stack (most recent call first):
  CMakeLists.txt:23 (FIND_PACKAGE)

Regards,
Yegor
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] CMake toolchain file changing shared library loading name [SOLVED]

[Дмитрий Дороговцев]

2013/7/19 Nils Gladitz 

>  When the library is being created by CMake itself I would have expected
> a SONAME by default:
> "Default is to set "soname" on all shared libraries and modules as long as
> the platform supports it."
>
> Is armLinux a valid value for CMAKE_SYSTEM_NAME?
> Quick glimpse at some documentation suggests you may want "Linux" instead
> since there are no armLinux platform files.
>
> I assume that may also set the proper flags for SONAME to work by
> default(?)
>
> Nils
>

You are right again :) So my general mistake was to provide custom-made
value for
CMAKE_SYSTEM_NAME, while preset one works fine, allowing to set correct name
of a shared library and thus making linker to setup correct dependency.
Thank you a lot.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake toolchain file changing shared library loading name

[Nils Gladitz]

When the library is being created by CMake itself I would have expected 
a SONAME by default:
"Default is to set "soname" on all shared libraries and modules as long 
as the platform supports it."


Is armLinux a valid value for CMAKE_SYSTEM_NAME?
Quick glimpse at some documentation suggests you may want "Linux" 
instead since there are no armLinux platform files.


I assume that may also set the proper flags for SONAME to work by default(?)

Nils

On 07/19/2013 11:31 AM, Дмитрий Дороговцев wrote:



2013/7/19 Nils Gladitz >


Does /home/mgh/proj/test/lib/libfoo.so not have a SONAME while
your native libfoo.so does?

The linker may use the SONAME when available and might fall back
to the path as seen on the command line
(/home/mgh/proj/test/lib/libfoo.so) otherwise?

Nils



Yes, you are totally right! I have explicitly set soname to library with
set( CMAKE_SHARED_LINKER_FLAGS "-Wl,-soname,libfoo.so" )
and after this final executable shows its dependencies as host one.
Thank you very much. I have one more question, though: should I
set soname every time explicitly or this should be done by toolchain
linker?



--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake toolchain file changing shared library loading name

[Дмитрий Дороговцев]

2013/7/19 Nils Gladitz 

>  Does /home/mgh/proj/test/lib/libfoo.so not have a SONAME while your
> native libfoo.so does?
>
> The linker may use the SONAME when available and might fall back to the
> path as seen on the command line (/home/mgh/proj/test/lib/libfoo.so)
> otherwise?
>
> Nils
>


Yes, you are totally right! I have explicitly set soname to library with
set( CMAKE_SHARED_LINKER_FLAGS "-Wl,-soname,libfoo.so" )
and after this final executable shows its dependencies as host one.
Thank you very much. I have one more question, though: should I
set soname every time explicitly or this should be done by toolchain
linker?
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake toolchain file changing shared library loading name

[m . hergarden]

On 07/19/2013 10:41 AM, ??? ?? wrote:
> Hello.
> I have a strange issue when cross compiling with CMake.
> When i compile for host, in the resulting binary i have:
>
> readelf -d ./test
> ...
> 0x0001 (NEEDED)  Shared library: [libfoo.so]
> 0x000f (RPATH)  Library rpath: [$ORIGIN/../../lib/]
> ...
>
> When i use CMake toolchain file (cmake -DCMAKE_TOOLCHAIN_FILE=arm_
> test.cmake .) i have:
> readelf -d ./test
> ...
> 0x0001 (NEEDED)  Shared library:
> [/home/mgh/proj/test/lib/libfoo.so]
> 0x000f (RPATH)  Library rpath: [$ORIGIN/../../lib/]
> ...
>
> My toolchain file is very simple:
>
> set( CMAKE_SYSTEM_NAME armLinux )
>
> set( CMAKE_C_COMPILER arm-linux-gnueabi-gcc )
> set( CMAKE_CXX_COMPILER arm-linux-gnueabi-g++ )
> set( CMAKE_FIND_ROOT_PATH /home/mgh/toolchains/arm-linux-gnueabi/bin )
>
> So my question is why path to libfoo.so has been changed in executable
> after
> cross compiling? Thank you.
>
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
Are you using find_library to locate the library? Setting the
CMAKE_FIND_ROOT_PATH influences the way libraries are found for
crosscompilation, but you may need to set
CMAKE_FIND_ROOT_PATH_MODE_LIBRARY as well, to make sure the right
library is found.

Regards,
Micha Hergarden

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake toolchain file changing shared library loading name

[Nils Gladitz]

Does /home/mgh/proj/test/lib/libfoo.so not have a SONAME while your 
native libfoo.so does?


The linker may use the SONAME when available and might fall back to the 
path as seen on the command line (/home/mgh/proj/test/lib/libfoo.so) 
otherwise?


Nils

On 07/19/2013 10:41 AM, Дмитрий Дороговцев wrote:

Hello.
I have a strange issue when cross compiling with CMake.
When i compile for host, in the resulting binary i have:

readelf -d ./test
...
0x0001 (NEEDED)  Shared library: [libfoo.so]
0x000f (RPATH)  Library rpath: [$ORIGIN/../../lib/]
...

When i use CMake toolchain file (cmake -DCMAKE_TOOLCHAIN_FILE=arm_
test.cmake .) i have:
readelf -d ./test
...
0x0001 (NEEDED)  Shared library: 
[/home/mgh/proj/test/lib/libfoo.so]

0x000f (RPATH)  Library rpath: [$ORIGIN/../../lib/]
...

My toolchain file is very simple:

set( CMAKE_SYSTEM_NAME armLinux )

set( CMAKE_C_COMPILER arm-linux-gnueabi-gcc )
set( CMAKE_CXX_COMPILER arm-linux-gnueabi-g++ )
set( CMAKE_FIND_ROOT_PATH /home/mgh/toolchains/arm-linux-gnueabi/bin )

So my question is why path to libfoo.so has been changed in executable 
after

cross compiling? Thank you.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] CMake toolchain file changing shared library loading name

[Дмитрий Дороговцев]

Hello.
I have a strange issue when cross compiling with CMake.
When i compile for host, in the resulting binary i have:

readelf -d ./test
...
0x0001 (NEEDED)  Shared library: [libfoo.so]
0x000f (RPATH)  Library rpath: [$ORIGIN/../../lib/]
...

When i use CMake toolchain file (cmake -DCMAKE_TOOLCHAIN_FILE=arm_
test.cmake .) i have:
readelf -d ./test
...
0x0001 (NEEDED)  Shared library:
[/home/mgh/proj/test/lib/libfoo.so]
0x000f (RPATH)  Library rpath: [$ORIGIN/../../lib/]
...

My toolchain file is very simple:

set( CMAKE_SYSTEM_NAME armLinux )

set( CMAKE_C_COMPILER arm-linux-gnueabi-gcc )
set( CMAKE_CXX_COMPILER arm-linux-gnueabi-g++ )
set( CMAKE_FIND_ROOT_PATH /home/mgh/toolchains/arm-linux-gnueabi/bin )

So my question is why path to libfoo.so has been changed in executable after
cross compiling? Thank you.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

On Mon, Mar 18, 2013 at 1:33 PM, Florian Reinhard <
florian.reinh...@googlemail.com> wrote:

> I still don't see that this is a valid reason to break things for others.
>

There is no any breakage. Qt has never been used with the TI toolchain. ABI
will be required from the start of the support.

Laszlo
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Florian Reinhard]

2013/3/18 Laszlo Papp :
> On Mon, Mar 18, 2013 at 1:10 PM, Florian Reinhard
>  wrote:
>>
>> In addition compilers upto 7.2 did not support anything else than coff
>> abi. So i don't see any valid reason to add --abi=eabi. Even more you
>> usually set your silicon for improved optimizer results with e.g
>> set_target_properties(myTarget PROPERTIES COMPILE_FLAGS "-mv6740")
>> and i see no reason not to add --abi=eabi there if one needs it.
>
>
> Well, EABI will most likely be upcoming as the default in the new TI
> versions. It will make no sense to use such an old legacy stuff mostly
> incompatible with the majority of the rest.
>
> Also, 7.2 was released a quite while ago, more than 2 years. If one still
> uses that version, that is likely a call for troubles. Texas Instruments
> discourage that, at least in our case, anyhow.
>
> By the way, Qt will have the EABI by default instead of the COFFABI. Here
> you can see the progress for that:
>
> https://codereview.qt-project.org/#change,51173
> https://codereview.qt-project.org/#change,51233
> https://codereview.qt-project.org/#change,51228
> https://codereview.qt-project.org/#change,51078
>
> ... and more to come.
>
> Laszlo
>

I still don't see that this is a valid reason to break things for others.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

On Mon, Mar 18, 2013 at 1:10 PM, Florian Reinhard <
florian.reinh...@googlemail.com> wrote:

> In addition compilers upto 7.2 did not support anything else than coff
> abi. So i don't see any valid reason to add --abi=eabi. Even more you
> usually set your silicon for improved optimizer results with e.g
> set_target_properties(myTarget PROPERTIES COMPILE_FLAGS "-mv6740")
> and i see no reason not to add --abi=eabi there if one needs it.
>

Well, EABI will most likely be upcoming as the default in the new TI
versions. It will make no sense to use such an old legacy stuff mostly
incompatible with the majority of the rest.

Also, 7.2 was released a quite while ago, more than 2 years. If one still
uses that version, that is likely a call for troubles. Texas Instruments
discourage that, at least in our case, anyhow.

By the way, Qt will have the EABI by default instead of the COFFABI. Here
you can see the progress for that:

https://codereview.qt-project.org/#change,51173
https://codereview.qt-project.org/#change,51233
https://codereview.qt-project.org/#change,51228
https://codereview.qt-project.org/#change,51078

... and more to come.

Laszlo
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Florian Reinhard]

2013/3/16 Laszlo Papp :
> On Thu, Mar 14, 2013 at 6:48 PM, Alexander Neundorf
>  wrote:
>>
>> Please verify that it works, so I can still get it into 2.8.11 hopefully.
>
>
> I just realized that the cmake files use the default ABI type which is still
> the legacy COFF, and not EABI.
>
> That is a bit unfortunate because we cannot put "--abi=eabi" in there due to
> the fact that the user would not be able to override that when COFF is
> desired. This is a toolchain limitation that you cannot define both, and the
> latter will be applied as one would think that.
>
> The consequence is that the majority of the people will need to define that
> explicitly. Unfortunately, not much we can do about it, but it is worth
> nothing.

In addition compilers upto 7.2 did not support anything else than coff
abi. So i don't see any valid reason to add --abi=eabi. Even more you
usually set your silicon for improved optimizer results with e.g
set_target_properties(myTarget PROPERTIES COMPILE_FLAGS "-mv6740")
and i see no reason not to add --abi=eabi there if one needs it.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Florian Reinhard]

2013/3/17 Alexander Neundorf :
> On Friday 15 March 2013, Florian Reinhard wrote:
>> I'm testing the next branch at the moment.
>> Changes i noticed:
>> setting the following options is no longer required (yay!):
>> SET (CMAKE_C_COMPILER_WORKS   1)
>> SET (CMAKE_CXX_COMPILER_WORKS 1)
>> #skip ABI checks
>> SET (CMAKE_DETERMINE_C_ABI_COMPILED   1)
>> SET (CMAKE_DETERMINE_CXX_ABI_COMPILED 1)
>> SET (CMAKE_DETERMINE_ASM_ABI_COMPILED 1)
>>
>> compiling with 6.2.22 works fine so far
>
> you also should not have to set CMAKE_AR and CMAKE_STRIP manually, they should
> be found now automatically.

i figured, that this only works if CMAKE_SYSTEM_NAME is set, which i
didn't do before
this did the trick:
set (CMAKE_SYSTEM_NAME "Generic")
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Alexander Neundorf]

On Friday 15 March 2013, Florian Reinhard wrote:
> I'm testing the next branch at the moment.
> Changes i noticed:
> setting the following options is no longer required (yay!):
> SET (CMAKE_C_COMPILER_WORKS   1)
> SET (CMAKE_CXX_COMPILER_WORKS 1)
> #skip ABI checks
> SET (CMAKE_DETERMINE_C_ABI_COMPILED   1)
> SET (CMAKE_DETERMINE_CXX_ABI_COMPILED 1)
> SET (CMAKE_DETERMINE_ASM_ABI_COMPILED 1)
> 
> compiling with 6.2.22 works fine so far

you also should not have to set CMAKE_AR and CMAKE_STRIP manually, they should 
be found now automatically.

Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

On Thu, Mar 14, 2013 at 6:48 PM, Alexander Neundorf  wrote:

> Please verify that it works, so I can still get it into 2.8.11 hopefully.
>

I just realized that the cmake files use the default ABI type which is
still the legacy COFF, and not EABI.

That is a bit unfortunate because we cannot put "--abi=eabi" in there due
to the fact that the user would not be able to override that when COFF is
desired. This is a toolchain limitation that you cannot define both, and
the latter will be applied as one would think that.

The consequence is that the majority of the people will need to define that
explicitly. Unfortunately, not much we can do about it, but it is worth
nothing.

Laszlo
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

On Fri, Mar 15, 2013 at 9:52 AM, Florian Reinhard <
florian.reinh...@googlemail.com> wrote:

> I'm testing the next branch at the moment.
> Changes i noticed:
> setting the following options is no longer required (yay!):
> SET (CMAKE_C_COMPILER_WORKS   1)
> SET (CMAKE_CXX_COMPILER_WORKS 1)
> #skip ABI checks
> SET (CMAKE_DETERMINE_C_ABI_COMPILED   1)
> SET (CMAKE_DETERMINE_CXX_ABI_COMPILED 1)
> SET (CMAKE_DETERMINE_ASM_ABI_COMPILED 1)
>

I personally never needed them.



>  questions:
> i still have to set CMAKE_C_COMPILER etc, what do i have to set, so
> cmake has a hint where to search for cl6x.exe?
>

I would guess it is not a TI specific question. You can do this for
instance:
https://projects.kde.org/projects/playground/mobile/wiki-reader/repository/revisions/master/entry/frontends/blackberry/cmake/Toolchain-C6X.cmake#L64

Perhaps, CMAKE_FIND_ROOT_PATH can also help, but the point is that cmake
cannot guess for you where you installed the environment. We used to have a
script (batch on Windows, and shell on Unix) for the Blackberry NDK that
the developers would run, but I am not aware of such a script from TI. I am
just setting that variable in my build script on top of cmake.

Laszlo
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Florian Reinhard]

I'm testing the next branch at the moment.
Changes i noticed:
setting the following options is no longer required (yay!):
SET (CMAKE_C_COMPILER_WORKS   1)
SET (CMAKE_CXX_COMPILER_WORKS 1)
#skip ABI checks
SET (CMAKE_DETERMINE_C_ABI_COMPILED   1)
SET (CMAKE_DETERMINE_CXX_ABI_COMPILED 1)
SET (CMAKE_DETERMINE_ASM_ABI_COMPILED 1)

compiling with 6.2.22 works fine so far

questions:
i still have to set CMAKE_C_COMPILER etc, what do i have to set, so
cmake has a hint where to search for cl6x.exe?

thumbs up so far!

2013/3/14 Alexander Neundorf :
> On Thursday 14 March 2013, Robert Maynard wrote:
>> I am sorry I was incorrect. The changes made to close bug 12405 are going
>> to be in RC1. These new changes aren't going to make RC1 but should be in
>> RC2 if we need one.
>
> I merged TI_DSP_to_TI_2 into next.
> It would be great if this could still make it into 2.8.11, since it changes
> the name of a still unreleased toolchain.
> Once this has been released, the name will have to be kept for compatibility
> reasons.
>
> Alex
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Robert Maynard]

Only for the RC1 candidate would the toolset name be wrong. We can make
sure that the proper toolset name goes into the final 2.8.11 release.


On Thu, Mar 14, 2013 at 4:57 PM, Alexander Neundorf  wrote:

> On Thursday 14 March 2013, Robert Maynard wrote:
> > I am sorry I was incorrect. The changes made to close bug 12405 are going
> > to be in RC1. These new changes aren't going to make RC1 but should be in
> > RC2 if we need one.
>
> I merged TI_DSP_to_TI_2 into next.
> It would be great if this could still make it into 2.8.11, since it changes
> the name of a still unreleased toolchain.
> Once this has been released, the name will have to be kept for
> compatibility
> reasons.
>
> Alex
>



-- 
Robert Maynard
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

On Thu, Mar 14, 2013 at 8:57 PM, Alexander Neundorf  wrote:

> On Thursday 14 March 2013, Robert Maynard wrote:
> > I am sorry I was incorrect. The changes made to close bug 12405 are going
> > to be in RC1. These new changes aren't going to make RC1 but should be in
> > RC2 if we need one.
>
> I merged TI_DSP_to_TI_2 into next.
> It would be great if this could still make it into 2.8.11, since it changes
> the name of a still unreleased toolchain.
> Once this has been released, the name will have to be kept for
> compatibility
> reasons.
>

I personally agree even if I do not know where it would be visible for the
end user (i.e. my using a toolchain file).

IMO, TI_DSP* is wrong because it whispers that it is a separate DSP
toolchain, and it is not. That is why I suggested TI_*. Hence, I would
either release it with the proper term, or postpone to 2.8.12.

Laszlo
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Alexander Neundorf]

On Thursday 14 March 2013, Robert Maynard wrote:
> I am sorry I was incorrect. The changes made to close bug 12405 are going
> to be in RC1. These new changes aren't going to make RC1 but should be in
> RC2 if we need one.

I merged TI_DSP_to_TI_2 into next.
It would be great if this could still make it into 2.8.11, since it changes 
the name of a still unreleased toolchain.
Once this has been released, the name will have to be kept for compatibility 
reasons.

Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Robert Maynard]

I am sorry I was incorrect. The changes made to close bug 12405 are going
to be in RC1. These new changes aren't going to make RC1 but should be in
RC2 if we need one.


On Thu, Mar 14, 2013 at 3:39 PM, Alexander Neundorf  wrote:

> On Thursday 14 March 2013, Robert Maynard wrote:
> > These changes will be in 2.8.11 RC1 for you to test out.
>
> Cool :-)
> Before I merge it into next, could you have a look at the TI_DSP_to_TI
> branch,
> I had some git trouble and I'm not quite sure everything is in this branch
> as
> it should...
>
> Thanks
> Alex
>



-- 
Robert Maynard
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Stephen Kelly]

Alexander Neundorf wrote:

> On Thursday 14 March 2013, Robert Maynard wrote:
>> These changes will be in 2.8.11 RC1 for you to test out.
> 
> Cool :-)
> Before I merge it into next, could you have a look at the TI_DSP_to_TI
> branch, I had some git trouble and I'm not quite sure everything is in
> this branch as it should...

You have a copy of a commit from Peter in your branch which shouldn't be 
there.

Run 'git rebase origin/master' and check the result with gitk before 
merging.

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Alexander Neundorf]

On Thursday 14 March 2013, Robert Maynard wrote:
> These changes will be in 2.8.11 RC1 for you to test out.

Cool :-)
Before I merge it into next, could you have a look at the TI_DSP_to_TI branch, 
I had some git trouble and I'm not quite sure everything is in this branch as 
it should...

Thanks
Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Robert Maynard]

These changes will be in 2.8.11 RC1 for you to test out.


On Thu, Mar 14, 2013 at 2:54 PM, Laszlo Papp  wrote:

> On Thu, Mar 14, 2013 at 6:48 PM, Alexander Neundorf <
> a.neundorf-w...@gmx.net> wrote:
>
>>  the TI_DSP_to_TI branch on cmake stage now tries to automatically
>> detect the
>> compiler prefix and suffix and searches ar and strip accordingly.
>> It seems to work for me (but I can't run the binaries).
>>
>> Please verify that it works, so I can still get it into 2.8.11 hopefully.
>>
>
> Great. If compiles, ship it! :)
>
> Beyond the joke. It will be a lot simpler for me to test this with a
> release candidate than now. I think this should be going into 2.8.11,
> anyway. It would be a definite improvement than what we currently have.
>
> Laszlo
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



-- 
Robert Maynard
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

On Thu, Mar 14, 2013 at 6:48 PM, Alexander Neundorf  wrote:

> the TI_DSP_to_TI branch on cmake stage now tries to automatically detect
> the
> compiler prefix and suffix and searches ar and strip accordingly.
> It seems to work for me (but I can't run the binaries).
>
> Please verify that it works, so I can still get it into 2.8.11 hopefully.
>

Great. If compiles, ship it! :)

Beyond the joke. It will be a lot simpler for me to test this with a
release candidate than now. I think this should be going into 2.8.11,
anyway. It would be a definite improvement than what we currently have.

Laszlo
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Alexander Neundorf]

On Thursday 14 March 2013, Laszlo Papp wrote:
> On Thu, Mar 14, 2013 at 8:59 AM, Florian Reinhard <
> 
> florian.reinh...@googlemail.com> wrote:
> > If ARM and DSP toolchain are commandline compatible, there could be an
> > option to specify the architecture, like C6000 (DSP core in OMAP
> > processors), C2000, C6400 which map to the correct
> > compiler/linker/archiver/strip names.
> 
> 1) Of course, TI for sure shares the language parser among the toolchains,
> so do they with the interface. It would not make too much sense otherwise.
> I bet it is only a historical issue why they do not use their binaries with
> the same names. Note that, they already migrated from cl470.exe to
> armcl.exe to be more generic across ARM cores. One step ahead could be that
> they even merge that with the DSP toolchain binaries in the future with a
> relevant target option, or perhaps not. It is not a biggie after all.
> 
> 2) I am not sure an option is a good idea. In fact, you need to specify the
> compiler executable (path) in your toolchain file, and once you specify
> that, the other executables match the naming schema quite well to be
> logical what their name would be.

the TI_DSP_to_TI branch on cmake stage now tries to automatically detect the 
compiler prefix and suffix and searches ar and strip accordingly.
It seems to work for me (but I can't run the binaries).

Please verify that it works, so I can still get it into 2.8.11 hopefully.

Thanks
Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

On Thu, Mar 14, 2013 at 8:59 AM, Florian Reinhard <
florian.reinh...@googlemail.com> wrote:

> If ARM and DSP toolchain are commandline compatible, there could be an
> option to specify the architecture, like C6000 (DSP core in OMAP
> processors), C2000, C6400 which map to the correct
> compiler/linker/archiver/strip names.
>

1) Of course, TI for sure shares the language parser among the toolchains,
so do they with the interface. It would not make too much sense otherwise.
I bet it is only a historical issue why they do not use their binaries with
the same names. Note that, they already migrated from cl470.exe to
armcl.exe to be more generic across ARM cores. One step ahead could be that
they even merge that with the DSP toolchain binaries in the future with a
relevant target option, or perhaps not. It is not a biggie after all.

2) I am not sure an option is a good idea. In fact, you need to specify the
compiler executable (path) in your toolchain file, and once you specify
that, the other executables match the naming schema quite well to be
logical what their name would be.

Laszlo
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Florian Reinhard]

If ARM and DSP toolchain are commandline compatible, there could be an
option to specify the architecture, like C6000 (DSP core in OMAP
processors), C2000, C6400 which map to the correct
compiler/linker/archiver/strip names.

2013/3/14 Laszlo Papp :
> On Wed, Mar 13, 2013 at 10:14 PM, Alexander Neundorf
>  wrote:
>>
>> Hi,
>>
>> it would be great if you could give the branch TI_DSP_to_TI on cmake stage
>> (
>> http://cmake.org/gitweb?p=stage/cmake.git ) a try.
>> It renames TI_DSP to TI, and searches for ar6x and strip6x.
>
>
> The binaries are called different for the ARM toolchain. As for less than
> v5, it is called cl470.exe, strip470.exe and so forth. As for greater than
> v4, it is called armcl.exe, armar.exe, armstrip.exe and so forth.
>
> Also, I will only be able try with the release candidate.
>
> Laszlo
>
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

On Wed, Mar 13, 2013 at 10:14 PM, Alexander Neundorf <
a.neundorf-w...@gmx.net> wrote:

> Hi,
>
> it would be great if you could give the branch TI_DSP_to_TI on cmake stage
> (
> http://cmake.org/gitweb?p=stage/cmake.git ) a try.
> It renames TI_DSP to TI, and searches for ar6x and strip6x.
>

The binaries are called different for the ARM toolchain. As for less than
v5, it is called cl470.exe, strip470.exe and so forth. As for greater than
v4, it is called armcl.exe, armar.exe, armstrip.exe and so forth.

Also, I will only be able try with the release candidate.

Laszlo
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Alexander Neundorf]

Hi,

it would be great if you could give the branch TI_DSP_to_TI on cmake stage ( 
http://cmake.org/gitweb?p=stage/cmake.git ) a try.
It renames TI_DSP to TI, and searches for ar6x and strip6x.

Thanks
Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Alexander Neundorf]

Hi Laszlo,

On Tuesday 12 March 2013, Laszlo Papp wrote:
> Oh, there is a "CMAKE_CXX_LINK_EXECUTABLE". That variable I did not know.
> It is nice to see that one does not need to force the compiler. That would
> be a bit nasty. :-)
> 
> This feature seems to come along with the 2.8.11 release which is in the
> door. I will try to write a blog post about this once we have the new
> release. :)

do you also have to set CMAKE_AR to ar6x and CMAKE_STRIP to strip6x for thr 
ARM compiler ?

Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Florian Reinhard]

When using the "linker" through CMAKE_CXX_LINK_EXECUTABLE you do not
need to add the --run-linker when compiling sources, which (i think)
is a bad idea.

If you have a setup and time, i'd appreciate if you could investigate
the crash of cmake upon the ABI tests (if they happen to you) since i
can't.

One more thing you might want to know about the cl6x:
if you happen to implement function "foo" in bar.cpp and the same
function is also implemented in library foobar.lib which you use for
linking, you would need to take care of the order of arguments to cl6x
while linking:
if bar.cpp.obj is before foobar.lib cl6x will use foo from bar.cpp.
you would have to do that manually, it's not possible to achieve this
with cmake from what i know.


2013/3/12 Laszlo Papp :
> Oh, there is a "CMAKE_CXX_LINK_EXECUTABLE". That variable I did not know. It
> is nice to see that one does not need to force the compiler. That would be a
> bit nasty. :-)
>
> This feature seems to come along with the 2.8.11 release which is in the
> door. I will try to write a blog post about this once we have the new
> release. :)
>
> Thank you for pointing this merge out.
>
>
> On Tue, Mar 12, 2013 at 9:09 AM, Florian Reinhard
>  wrote:
>>
>> 1. drop the TI_DSP*.cmake you can find linked below in your
>> cmake/Modules/Compiler folder, i assumed this was already released
>> since Alexander Neundorf merged the changes back in november
>>
>>
>> http://cmake.org/gitweb?p=cmake.git;a=tree;f=Modules/Compiler;h=34a0ad1a5694082dc8ffc62c2ebeaa446ea09274;hb=master
>>
>>
>> 2. set your compiler in the following way, just replace/set CGT_DIR.
>> as you can see from the comment, the commands are sensible to the
>> order:
>> SET (CMAKE_C_COMPILER "${CGT_DIR}/bin/cl6x.exe")
>> SET (CMAKE_CXX_COMPILER ${CMAKE_C_COMPILER})
>> SET (CMAKE_ASM_COMPILER ${CMAKE_C_COMPILER})
>> SET (CMAKE_CXX_LINK_EXECUTABLE ${CMAKE_C_COMPILER})
>> SET (CMAKE_STRIP "${CGT_DIR}/bin/strip6x.exe")
>>
>> # We do want to compile assembler files as well
>> ENABLE_LANGUAGE(ASM)
>>
>> # must be done after enabling ASM since it overwrites CMAKE_AR
>> SET (CMAKE_AR "${CGT_DIR}/bin/ar6x.exe")
>>
>>
>> 3. if you encounter problems while cmake does compiler tests add the
>> following
>> SET (CMAKE_C_COMPILER_WORKS   1)
>> SET (CMAKE_CXX_COMPILER_WORKS 1)
>> #skip ABI checks
>> SET (CMAKE_DETERMINE_C_ABI_COMPILED   1)
>> SET (CMAKE_DETERMINE_CXX_ABI_COMPILED 1)
>> SET (CMAKE_DETERMINE_ASM_ABI_COMPILED 1)
>>
>> in my case on windows 7 with cl6x 6.2.*, cmake would just crash. i
>> think this is what you encounter as well. maybe jom just hides that
>> crash. unfortunately i have not the knowledge to investigate this on
>> windows.
>>
>> 4. if you compile libraries as well you might need the following:
>> UNSET (CMAKE_C_ARCHIVE_FINISH)
>> UNSET (CMAKE_CXX_ARCHIVE_FINISH)
>>
>> Kind Regards,
>>
>> Florian Reinhard
>>
>> 2013/2/22 Laszlo Papp :
>> > Hi,
>> >
>> > I am now trying to put a toolchain file together for the aforementioned
>> > embedded environment on my Windows 7 workstation. You can see the file
>> > contents I have, and the errors I get below. When I just use the
>> > compiler
>> > against the one liner main.c, it works off hand. I also tried to force
>> > the
>> > C/C++ compilers, but even though the cmake ran fine, jom failed pretty
>> > much
>> > with the same error.
>> >
>> > Any help is much appreciated!
>> >
>> > Laszlo
>> >
>> > -
>> >
>> > main.c
>> >
>> > int main() {return 0;}
>> >
>> > CMakeLists.txt
>> >
>> > add_executable(skeleton main.c)
>> >
>> > ToolchainFile-C6000
>> >
>> > # include("CMakeForceCompiler")
>> >
>> > set(CMAKE_SYSTEM_NAME "Sysbios")
>> > set(CMAKE_SYSTEM_VERSION "1.0")
>> > set(CMAKE_SYSTEM_PROCESSOR "C6000")
>> >
>> > set(CMAKE_FIND_ROOT_PATH"${CMAKE_FIND_ROOT_PATH}"
>> > "C:/ti/C6000 Code Generation Tools 7.3.0B3/bin"
>> > "C:/ti/C6000 Code Generation Tools 7.3.0B3/include"
>> > "C:/ti/C6000 Code Generation Tools 7.3.0B3/lib")
>> >
>> > # CMAKE_FORCE_C_COMPILER("C:/ti/C6000 Code Generation Tools
>> > 7.3.0B3/bin/cl6x.exe" "TI")
>> > # CMAKE_FORCE_CXX_COMPILER("C:/ti/C6000 Code Generation Tools
>> > 7.3.0B3/bin/cl6x.exe" "TI")
>> >
>> > SET(CMAKE_C_COMPILER  "C:/ti/C6000 Code Generation Tools
>> > 7.3.0B3/bin/cl6x.exe")
>> > SET(CMAKE_CXX_COMPILER  "C:/ti/C6000 Code Generation Tools
>> > 7.3.0B3/bin/cl6x.exe")
>> >
>> > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAMBOTH)
>> > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDEBOTH)
>> > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARYONLY)
>> >
>> > ERROR
>> >
>> > cmake -G "NMake Makefiles JOM"
>> > -DCMAKE_TOOLCHAIN_FILE=../toolchain-cl6x.cmake ..
>> > -- The C compiler identification is TI_DSP 7.3.0
>> > -- The CXX compiler identification is TI_DSP 7.3.0
>> > -- Check for working C compiler: C:/ti/C6000 Code Generation Tools
>> > 7.3.0B3/bin/c
>> > l6x.exe
>> > -- Check for working C compiler: C:/ti/C6000 Code 

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

Oh, there is a "CMAKE_CXX_LINK_EXECUTABLE". That variable I did not know.
It is nice to see that one does not need to force the compiler. That would
be a bit nasty. :-)

This feature seems to come along with the 2.8.11 release which is in the
door. I will try to write a blog post about this once we have the new
release. :)

Thank you for pointing this merge out.

On Tue, Mar 12, 2013 at 9:09 AM, Florian Reinhard <
florian.reinh...@googlemail.com> wrote:

> 1. drop the TI_DSP*.cmake you can find linked below in your
> cmake/Modules/Compiler folder, i assumed this was already released
> since Alexander Neundorf merged the changes back in november
>
>
> http://cmake.org/gitweb?p=cmake.git;a=tree;f=Modules/Compiler;h=34a0ad1a5694082dc8ffc62c2ebeaa446ea09274;hb=master
>
>
> 2. set your compiler in the following way, just replace/set CGT_DIR.
> as you can see from the comment, the commands are sensible to the
> order:
> SET (CMAKE_C_COMPILER "${CGT_DIR}/bin/cl6x.exe")
> SET (CMAKE_CXX_COMPILER ${CMAKE_C_COMPILER})
> SET (CMAKE_ASM_COMPILER ${CMAKE_C_COMPILER})
> SET (CMAKE_CXX_LINK_EXECUTABLE ${CMAKE_C_COMPILER})
> SET (CMAKE_STRIP "${CGT_DIR}/bin/strip6x.exe")
>
> # We do want to compile assembler files as well
> ENABLE_LANGUAGE(ASM)
>
> # must be done after enabling ASM since it overwrites CMAKE_AR
> SET (CMAKE_AR "${CGT_DIR}/bin/ar6x.exe")
>
>
> 3. if you encounter problems while cmake does compiler tests add the
> following
> SET (CMAKE_C_COMPILER_WORKS   1)
> SET (CMAKE_CXX_COMPILER_WORKS 1)
> #skip ABI checks
> SET (CMAKE_DETERMINE_C_ABI_COMPILED   1)
> SET (CMAKE_DETERMINE_CXX_ABI_COMPILED 1)
> SET (CMAKE_DETERMINE_ASM_ABI_COMPILED 1)
>
> in my case on windows 7 with cl6x 6.2.*, cmake would just crash. i
> think this is what you encounter as well. maybe jom just hides that
> crash. unfortunately i have not the knowledge to investigate this on
> windows.
>
> 4. if you compile libraries as well you might need the following:
> UNSET (CMAKE_C_ARCHIVE_FINISH)
> UNSET (CMAKE_CXX_ARCHIVE_FINISH)
>
> Kind Regards,
>
> Florian Reinhard
>
> 2013/2/22 Laszlo Papp :
> > Hi,
> >
> > I am now trying to put a toolchain file together for the aforementioned
> > embedded environment on my Windows 7 workstation. You can see the file
> > contents I have, and the errors I get below. When I just use the compiler
> > against the one liner main.c, it works off hand. I also tried to force
> the
> > C/C++ compilers, but even though the cmake ran fine, jom failed pretty
> much
> > with the same error.
> >
> > Any help is much appreciated!
> >
> > Laszlo
> >
> > -
> >
> > main.c
> >
> > int main() {return 0;}
> >
> > CMakeLists.txt
> >
> > add_executable(skeleton main.c)
> >
> > ToolchainFile-C6000
> >
> > # include("CMakeForceCompiler")
> >
> > set(CMAKE_SYSTEM_NAME "Sysbios")
> > set(CMAKE_SYSTEM_VERSION "1.0")
> > set(CMAKE_SYSTEM_PROCESSOR "C6000")
> >
> > set(CMAKE_FIND_ROOT_PATH"${CMAKE_FIND_ROOT_PATH}"
> > "C:/ti/C6000 Code Generation Tools 7.3.0B3/bin"
> > "C:/ti/C6000 Code Generation Tools 7.3.0B3/include"
> > "C:/ti/C6000 Code Generation Tools 7.3.0B3/lib")
> >
> > # CMAKE_FORCE_C_COMPILER("C:/ti/C6000 Code Generation Tools
> > 7.3.0B3/bin/cl6x.exe" "TI")
> > # CMAKE_FORCE_CXX_COMPILER("C:/ti/C6000 Code Generation Tools
> > 7.3.0B3/bin/cl6x.exe" "TI")
> >
> > SET(CMAKE_C_COMPILER  "C:/ti/C6000 Code Generation Tools
> > 7.3.0B3/bin/cl6x.exe")
> > SET(CMAKE_CXX_COMPILER  "C:/ti/C6000 Code Generation Tools
> > 7.3.0B3/bin/cl6x.exe")
> >
> > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAMBOTH)
> > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDEBOTH)
> > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARYONLY)
> >
> > ERROR
> >
> > cmake -G "NMake Makefiles JOM"
> > -DCMAKE_TOOLCHAIN_FILE=../toolchain-cl6x.cmake ..
> > -- The C compiler identification is TI_DSP 7.3.0
> > -- The CXX compiler identification is TI_DSP 7.3.0
> > -- Check for working C compiler: C:/ti/C6000 Code Generation Tools
> > 7.3.0B3/bin/c
> > l6x.exe
> > -- Check for working C compiler: C:/ti/C6000 Code Generation Tools
> > 7.3.0B3/bin/c
> > l6x.exe -- broken
> > CMake Error at C:/Program Files (x86)/CMake
> > 2.8/share/cmake-2.8/Modules/CMakeTes
> > tCCompiler.cmake:61 (message):
> >   The C compiler "C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/cl6x.exe" is
> >   not able to compile a simple test program.
> >
> >   It fails with the following output:
> >
> >Change Dir: C:/Projects/share/skeleton/build/CMakeFiles/CMakeTmp
> >
> >
> >
> >   Run Build Command:jom "cmTryCompileExec2474985119\fast"
> >
> >
> >
> >   jom 1.0.13 - empower your cores
> >
> >
> >
> > "C:\Program Files (x86)\jom\jom.exe" -f
> >   CMakeFiles\cmTryCompileExec2474985119.dir\build.make /nologo -
> >   CMakeFiles\cmTryCompileExec2474985119.dir\build
> >
> > "C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E
> > cmake_progress_repor
> > t
> >   C:\Projects\share\skeleton\b

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Florian Reinhard]

1. drop the TI_DSP*.cmake you can find linked below in your
cmake/Modules/Compiler folder, i assumed this was already released
since Alexander Neundorf merged the changes back in november

http://cmake.org/gitweb?p=cmake.git;a=tree;f=Modules/Compiler;h=34a0ad1a5694082dc8ffc62c2ebeaa446ea09274;hb=master


2. set your compiler in the following way, just replace/set CGT_DIR.
as you can see from the comment, the commands are sensible to the
order:
SET (CMAKE_C_COMPILER "${CGT_DIR}/bin/cl6x.exe")
SET (CMAKE_CXX_COMPILER ${CMAKE_C_COMPILER})
SET (CMAKE_ASM_COMPILER ${CMAKE_C_COMPILER})
SET (CMAKE_CXX_LINK_EXECUTABLE ${CMAKE_C_COMPILER})
SET (CMAKE_STRIP "${CGT_DIR}/bin/strip6x.exe")

# We do want to compile assembler files as well
ENABLE_LANGUAGE(ASM)

# must be done after enabling ASM since it overwrites CMAKE_AR
SET (CMAKE_AR "${CGT_DIR}/bin/ar6x.exe")


3. if you encounter problems while cmake does compiler tests add the following
SET (CMAKE_C_COMPILER_WORKS   1)
SET (CMAKE_CXX_COMPILER_WORKS 1)
#skip ABI checks
SET (CMAKE_DETERMINE_C_ABI_COMPILED   1)
SET (CMAKE_DETERMINE_CXX_ABI_COMPILED 1)
SET (CMAKE_DETERMINE_ASM_ABI_COMPILED 1)

in my case on windows 7 with cl6x 6.2.*, cmake would just crash. i
think this is what you encounter as well. maybe jom just hides that
crash. unfortunately i have not the knowledge to investigate this on
windows.

4. if you compile libraries as well you might need the following:
UNSET (CMAKE_C_ARCHIVE_FINISH)
UNSET (CMAKE_CXX_ARCHIVE_FINISH)

Kind Regards,

Florian Reinhard

2013/2/22 Laszlo Papp :
> Hi,
>
> I am now trying to put a toolchain file together for the aforementioned
> embedded environment on my Windows 7 workstation. You can see the file
> contents I have, and the errors I get below. When I just use the compiler
> against the one liner main.c, it works off hand. I also tried to force the
> C/C++ compilers, but even though the cmake ran fine, jom failed pretty much
> with the same error.
>
> Any help is much appreciated!
>
> Laszlo
>
> -
>
> main.c
>
> int main() {return 0;}
>
> CMakeLists.txt
>
> add_executable(skeleton main.c)
>
> ToolchainFile-C6000
>
> # include("CMakeForceCompiler")
>
> set(CMAKE_SYSTEM_NAME "Sysbios")
> set(CMAKE_SYSTEM_VERSION "1.0")
> set(CMAKE_SYSTEM_PROCESSOR "C6000")
>
> set(CMAKE_FIND_ROOT_PATH"${CMAKE_FIND_ROOT_PATH}"
> "C:/ti/C6000 Code Generation Tools 7.3.0B3/bin"
> "C:/ti/C6000 Code Generation Tools 7.3.0B3/include"
> "C:/ti/C6000 Code Generation Tools 7.3.0B3/lib")
>
> # CMAKE_FORCE_C_COMPILER("C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/cl6x.exe" "TI")
> # CMAKE_FORCE_CXX_COMPILER("C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/cl6x.exe" "TI")
>
> SET(CMAKE_C_COMPILER  "C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/cl6x.exe")
> SET(CMAKE_CXX_COMPILER  "C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/cl6x.exe")
>
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAMBOTH)
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDEBOTH)
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARYONLY)
>
> ERROR
>
> cmake -G "NMake Makefiles JOM"
> -DCMAKE_TOOLCHAIN_FILE=../toolchain-cl6x.cmake ..
> -- The C compiler identification is TI_DSP 7.3.0
> -- The CXX compiler identification is TI_DSP 7.3.0
> -- Check for working C compiler: C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/c
> l6x.exe
> -- Check for working C compiler: C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/c
> l6x.exe -- broken
> CMake Error at C:/Program Files (x86)/CMake
> 2.8/share/cmake-2.8/Modules/CMakeTes
> tCCompiler.cmake:61 (message):
>   The C compiler "C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/cl6x.exe" is
>   not able to compile a simple test program.
>
>   It fails with the following output:
>
>Change Dir: C:/Projects/share/skeleton/build/CMakeFiles/CMakeTmp
>
>
>
>   Run Build Command:jom "cmTryCompileExec2474985119\fast"
>
>
>
>   jom 1.0.13 - empower your cores
>
>
>
> "C:\Program Files (x86)\jom\jom.exe" -f
>   CMakeFiles\cmTryCompileExec2474985119.dir\build.make /nologo -
>   CMakeFiles\cmTryCompileExec2474985119.dir\build
>
> "C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E
> cmake_progress_repor
> t
>   C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles 1
>
>   Building C object
>   CMakeFiles/cmTryCompileExec2474985119.dir/testCCompiler.c.obj
>
> C:\ti\C6000C~1.0B3\bin\cl6x.exe -o
>   CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj -c
>   C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\testCCompiler.c
>
>   [testCCompiler.c]
>
>   >> WARNING: object file specified, but linking not enabled
>
>   Linking C executable cmTryCompileExec2474985119
>
> C:\ti\C6000C~1.0B3\bin\cl6x.exe
>   "CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj" -o
>   cmTryCompileExec2474985119
>
>   [cmTryCompileExec2474985119.]
>
>   >> WARNING: object file specified, but linking not enabled
>
>   Fatal error: c

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Florian Reinhard]

Hi Lazlo,

my setup: i'm using the MinGW makefile generator and build with make 3.82 on 
windows 7.

I did disable all tests that cmake automatically does, in my case cmake just 
crashed and i was not able to debug that on windows, if you can digg into 
this, i'd appreciate this as well :). 

Concerning the --runlinker issue. i never had a project with just one 
sourcefile. You probably just don't want to use cl6x as compiler and linker at 
the same time. just let cmake do two calls of cl6x.

If this still doesn't help, i'll try to remember to send you my toolchainfile 
next week.

btw: do you know about linker command files for the cl6x? they let you specify 
where to put code: L2 ram/cache, external or shared memory.

Kind Regards,
F

On Friday 22 February 2013 20:35:45 Laszlo Papp wrote:

Hi,

I am now trying to put a toolchain file together for the aforementioned 
embedded environment on my Windows 7 workstation. You can see the file contents 
I have, and the errors I get below. When I just use the compiler against the 
one liner main.c, it works off hand. I also tried to force the C/C++ compilers, 
but even though the cmake ran fine, jom failed pretty much with the same error.

Any help is much appreciated!

Laszlo

-

main.c

int main() {return 0;}

CMakeLists.txt

add_executable(skeleton main.c)

ToolchainFile-C6000

# include("CMakeForceCompiler")

set(CMAKE_SYSTEM_NAME "Sysbios")
set(CMAKE_SYSTEM_VERSION "1.0")
set(CMAKE_SYSTEM_PROCESSOR "C6000")

set(CMAKE_FIND_ROOT_PATH"${CMAKE_FIND_ROOT_PATH}"
"C:/ti/C6000 Code Generation Tools 7.3.0B3/bin"
"C:/ti/C6000 Code Generation Tools 7.3.0B3/include"
"C:/ti/C6000 Code Generation Tools 7.3.0B3/lib")

# CMAKE_FORCE_C_COMPILER("C:/ti/C6000 Code Generation Tools 
7.3.0B3/bin/cl6x.exe" "TI")
# CMAKE_FORCE_CXX_COMPILER("C:/ti/C6000 Code Generation Tools 
7.3.0B3/bin/cl6x.exe" "TI")

SET(CMAKE_C_COMPILER  "C:/ti/C6000 Code Generation Tools 
7.3.0B3/bin/cl6x.exe")
SET(CMAKE_CXX_COMPILER  "C:/ti/C6000 Code Generation Tools 
7.3.0B3/bin/cl6x.exe")

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAMBOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDEBOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARYONLY)

ERROR

cmake -G "NMake Makefiles JOM" -DCMAKE_TOOLCHAIN_FILE=../toolchain-cl6x.cmake ..
-- The C compiler identification is TI_DSP 7.3.0
-- The CXX compiler identification is TI_DSP 7.3.0
-- Check for working C compiler: C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/c
l6x.exe
-- Check for working C compiler: C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/c
l6x.exe -- broken
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTes
tCCompiler.cmake:61 (message):
  The C compiler "C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/cl6x.exe" is
  not able to compile a simple test program.

  It fails with the following output:

   Change Dir: C:/Projects/share/skeleton/build/CMakeFiles/CMakeTmp



  Run Build Command:jom "cmTryCompileExec2474985119\fast"



  jom 1.0.13 - empower your cores



"C:\Program Files (x86)\jom\jom.exe" -f
  CMakeFiles\cmTryCompileExec2474985119.dir\build.make /nologo -
  CMakeFiles\cmTryCompileExec2474985119.dir\build

"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_progress_repor
t
  C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles 1

  Building C object
  CMakeFiles/cmTryCompileExec2474985119.dir/testCCompiler.c.obj

C:\ti\C6000C~1.0B3\bin\cl6x.exe -o
  CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj -c
  C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\testCCompiler.c

  [testCCompiler.c]

  >> WARNING: object file specified, but linking not enabled

  Linking C executable cmTryCompileExec2474985119

C:\ti\C6000C~1.0B3\bin\cl6x.exe
  "CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj" -o
  cmTryCompileExec2474985119

  [cmTryCompileExec2474985119.]

  >> WARNING: object file specified, but linking not enabled

  Fatal error: could not open source file "cmTryCompileExec2474985119"

  1 fatal error detected in the compilation of "cmTryCompileExec2474985119".

  Compilation terminated.



  jom:
  C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles\cmTryCompileEx
ec2474985119.dir\build.make
  [cmTryCompileExec2474985119] Error 1

  >> Compilation failure

  jom: C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\Makefile
  [cmTryCompileExec2474985119\fast] Error 2





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):



-- Configuring incomplete, errors occurred!

C:\Projects\share\skeleton\build>


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

>
> Anyone knowing something about this?


Issue still not solved. :-)

Laszlo
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

Shall I force the compiler?

This is all I can find on the "CMake Cross Compiling" wiki: "If your
compiler is not able to build a simple program by default without special
flags or files (e.g. linker scripts or memory layout files), the toolchain
file as shown above doesn't work. Then you have to *force* the compiler:"

It would be nice to have a bit more thorough documentation. This is not yet
clear to me if it applies against my scenario or I can avoid forcing.

Anyone knowing something about this?

On Sun, Feb 24, 2013 at 10:28 PM, Laszlo Papp  wrote:

> Here you can find the toolchain file I created:
> https://projects.kde.org/projects/playground/mobile/wiki-reader/repository/revisions/master/entry/frontends/blackberry/cmake/Toolchain-C6X.cmake
>
> I think the issue boils down to this:
>
> root /home/lpapp/Projects/qt/skeleton/build # /opt/ti/C6000CGT7.4.2/bin/cl6x 
> --abi=eabi --run_linker ../main.c
> 
> "../main.c", line 1: error: cannot find file "int"
> "../main.c", line 1: error: cannot find file "main"
> "../main.c", line 1: error: expecting filename, option, MEMORY, or SECTIONS
>instead of "("
> "../main.c", line 4: error: expecting filename, option, MEMORY, or SECTIONS
>instead of "}"
> fatal error: no input files
>
> >> Compilation failure
> root /home/lpapp/Projects/qt/skeleton/build # /opt/ti/C6000CGT7.4.2/bin/cl6x 
> --abi=eabi ../main.c --run_linker
> 
> warning: automatic library build: using library
>"/opt/ti/C6000CGT7.4.2/lib/rts6200_elf.lib" for the first time, so it must
>be built.  This may take a few minutes.
>
> Do you have any ideas how to solve this issue? It seems to me that, I
> would need to pass the source files before the linker option.
>
> Laszlo
>
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

Here you can find the toolchain file I created:
https://projects.kde.org/projects/playground/mobile/wiki-reader/repository/revisions/master/entry/frontends/blackberry/cmake/Toolchain-C6X.cmake

I think the issue boils down to this:

root /home/lpapp/Projects/qt/skeleton/build #
/opt/ti/C6000CGT7.4.2/bin/cl6x --abi=eabi --run_linker ../main.c

"../main.c", line 1: error: cannot find file "int"
"../main.c", line 1: error: cannot find file "main"
"../main.c", line 1: error: expecting filename, option, MEMORY, or SECTIONS
   instead of "("
"../main.c", line 4: error: expecting filename, option, MEMORY, or SECTIONS
   instead of "}"
fatal error: no input files

>> Compilation failure
root /home/lpapp/Projects/qt/skeleton/build #
/opt/ti/C6000CGT7.4.2/bin/cl6x --abi=eabi ../main.c --run_linker

warning: automatic library build: using library
   "/opt/ti/C6000CGT7.4.2/lib/rts6200_elf.lib" for the first time, so it must
   be built.  This may take a few minutes.

Do you have any ideas how to solve this issue? It seems to me that, I would
need to pass the source files before the linker option.

Laszlo
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

Oh, I might need to use the --run_linker (or --compile_only tentatively at
least) argument for the compiler. I will try that with
"CMAKE_C(XX)_COMPILER_ARG1". Apologize for the noise.

On Fri, Feb 22, 2013 at 8:35 PM, Laszlo Papp  wrote:

> Hi,
>
> I am now trying to put a toolchain file together for the aforementioned
> embedded environment on my Windows 7 workstation. You can see the file
> contents I have, and the errors I get below. When I just use the compiler
> against the one liner main.c, it works off hand. I also tried to force the
> C/C++ compilers, but even though the cmake ran fine, jom failed pretty much
> with the same error.
>
> Any help is much appreciated!
>
> Laszlo
>
> -
> *
> main.c*
>
> int main() {return 0;}
>
> *CMakeLists.txt*
>
> add_executable(skeleton main.c)
>
> *ToolchainFile-C6000*
>
> # include("CMakeForceCompiler")
>
> set(CMAKE_SYSTEM_NAME "Sysbios")
> set(CMAKE_SYSTEM_VERSION "1.0")
> set(CMAKE_SYSTEM_PROCESSOR "C6000")
>
> set(CMAKE_FIND_ROOT_PATH"${CMAKE_FIND_ROOT_PATH}"
> "C:/ti/C6000 Code Generation Tools 7.3.0B3/bin"
> "C:/ti/C6000 Code Generation Tools 7.3.0B3/include"
> "C:/ti/C6000 Code Generation Tools 7.3.0B3/lib")
>
> # CMAKE_FORCE_C_COMPILER("C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/cl6x.exe" "TI")
> # CMAKE_FORCE_CXX_COMPILER("C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/cl6x.exe" "TI")
>
> SET(CMAKE_C_COMPILER  "C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/cl6x.exe")
> SET(CMAKE_CXX_COMPILER  "C:/ti/C6000 Code Generation Tools
> 7.3.0B3/bin/cl6x.exe")
>
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAMBOTH)
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDEBOTH)
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARYONLY)
>
> *ERROR
> *
>
> cmake -G "NMake Makefiles JOM" -DCMAKE_TOOLCHAIN_FILE=../toolchain-cl6x.cmake 
> ..
> -- The C compiler identification is TI_DSP 7.3.0
> -- The CXX compiler identification is TI_DSP 7.3.0
> -- Check for working C compiler: C:/ti/C6000 Code Generation Tools 
> 7.3.0B3/bin/c
> l6x.exe
> -- Check for working C compiler: C:/ti/C6000 Code Generation Tools 
> 7.3.0B3/bin/c
> l6x.exe -- broken
> CMake Error at C:/Program Files (x86)/CMake 
> 2.8/share/cmake-2.8/Modules/CMakeTes
> tCCompiler.cmake:61 (message):
>   The C compiler "C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/cl6x.exe" is
>   not able to compile a simple test program.
>
>   It fails with the following output:
>
>Change Dir: C:/Projects/share/skeleton/build/CMakeFiles/CMakeTmp
>
>
>
>   Run Build Command:jom "cmTryCompileExec2474985119\fast"
>
>
>
>   jom 1.0.13 - empower your cores
>
>
>
> "C:\Program Files (x86)\jom\jom.exe" -f
>   CMakeFiles\cmTryCompileExec2474985119.dir\build.make /nologo -
>   CMakeFiles\cmTryCompileExec2474985119.dir\build
>
> "C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E 
> cmake_progress_repor
> t
>   C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles 1
>
>   Building C object
>   CMakeFiles/cmTryCompileExec2474985119.dir/testCCompiler.c.obj
>
> C:\ti\C6000C~1.0B3\bin\cl6x.exe -o
>   CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj -c
>   C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\testCCompiler.c
>
>   [testCCompiler.c]
>
>   >> WARNING: object file specified, but linking not enabled
>
>   Linking C executable cmTryCompileExec2474985119
>
> C:\ti\C6000C~1.0B3\bin\cl6x.exe
>   "CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj" -o
>   cmTryCompileExec2474985119
>
>   [cmTryCompileExec2474985119.]
>
>   >> WARNING: object file specified, but linking not enabled
>
>   Fatal error: could not open source file "cmTryCompileExec2474985119"
>
>   1 fatal error detected in the compilation of "cmTryCompileExec2474985119".
>
>   Compilation terminated.
>
>
>
>   jom:
>   
> C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles\cmTryCompileEx
> ec2474985119.dir\build.make
>   [cmTryCompileExec2474985119] Error 1
>
>   >> Compilation failure
>
>   jom: C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\Makefile
>   [cmTryCompileExec2474985119\fast] Error 2
>
>
>
>
>
>   CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>
>
>
> -- Configuring incomplete, errors occurred!
>
> C:\Projects\share\skeleton\build>
>
>
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Toolchain file: Texas Instrument C6000 Code Generation Tools

[Laszlo Papp]

Hi,

I am now trying to put a toolchain file together for the aforementioned
embedded environment on my Windows 7 workstation. You can see the file
contents I have, and the errors I get below. When I just use the compiler
against the one liner main.c, it works off hand. I also tried to force the
C/C++ compilers, but even though the cmake ran fine, jom failed pretty much
with the same error.

Any help is much appreciated!

Laszlo

-
*
main.c*

int main() {return 0;}

*CMakeLists.txt*

add_executable(skeleton main.c)

*ToolchainFile-C6000*

# include("CMakeForceCompiler")

set(CMAKE_SYSTEM_NAME "Sysbios")
set(CMAKE_SYSTEM_VERSION "1.0")
set(CMAKE_SYSTEM_PROCESSOR "C6000")

set(CMAKE_FIND_ROOT_PATH"${CMAKE_FIND_ROOT_PATH}"
"C:/ti/C6000 Code Generation Tools 7.3.0B3/bin"
"C:/ti/C6000 Code Generation Tools 7.3.0B3/include"
"C:/ti/C6000 Code Generation Tools 7.3.0B3/lib")

# CMAKE_FORCE_C_COMPILER("C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe" "TI")
# CMAKE_FORCE_CXX_COMPILER("C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe" "TI")

SET(CMAKE_C_COMPILER  "C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe")
SET(CMAKE_CXX_COMPILER  "C:/ti/C6000 Code Generation Tools
7.3.0B3/bin/cl6x.exe")

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAMBOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDEBOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARYONLY)

*ERROR
*

cmake -G "NMake Makefiles JOM" -DCMAKE_TOOLCHAIN_FILE=../toolchain-cl6x.cmake ..
-- The C compiler identification is TI_DSP 7.3.0
-- The CXX compiler identification is TI_DSP 7.3.0
-- Check for working C compiler: C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/c
l6x.exe
-- Check for working C compiler: C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/c
l6x.exe -- broken
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTes
tCCompiler.cmake:61 (message):
  The C compiler "C:/ti/C6000 Code Generation Tools 7.3.0B3/bin/cl6x.exe" is
  not able to compile a simple test program.

  It fails with the following output:

   Change Dir: C:/Projects/share/skeleton/build/CMakeFiles/CMakeTmp



  Run Build Command:jom "cmTryCompileExec2474985119\fast"



  jom 1.0.13 - empower your cores



"C:\Program Files (x86)\jom\jom.exe" -f
  CMakeFiles\cmTryCompileExec2474985119.dir\build.make /nologo -
  CMakeFiles\cmTryCompileExec2474985119.dir\build

"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_progress_repor
t
  C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles 1

  Building C object
  CMakeFiles/cmTryCompileExec2474985119.dir/testCCompiler.c.obj

C:\ti\C6000C~1.0B3\bin\cl6x.exe -o
  CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj -c
  C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\testCCompiler.c

  [testCCompiler.c]

  >> WARNING: object file specified, but linking not enabled

  Linking C executable cmTryCompileExec2474985119

C:\ti\C6000C~1.0B3\bin\cl6x.exe
  "CMakeFiles\cmTryCompileExec2474985119.dir\testCCompiler.c.obj" -o
  cmTryCompileExec2474985119

  [cmTryCompileExec2474985119.]

  >> WARNING: object file specified, but linking not enabled

  Fatal error: could not open source file "cmTryCompileExec2474985119"

  1 fatal error detected in the compilation of "cmTryCompileExec2474985119".

  Compilation terminated.



  jom:
  C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\CMakeFiles\cmTryCompileEx
ec2474985119.dir\build.make
  [cmTryCompileExec2474985119] Error 1

  >> Compilation failure

  jom: C:\Projects\share\skeleton\build\CMakeFiles\CMakeTmp\Makefile
  [cmTryCompileExec2474985119\fast] Error 2





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):



-- Configuring incomplete, errors occurred!

C:\Projects\share\skeleton\build>
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake toolchain and FIND_PACKAGE(OpenSSL)

[Boards Killer]

>>> I'm pretty sure LINK_DIRECTORIES should not be used in toolchain
>>> if not use at all.
>>>
>>> The purpose of find_package is precisely to find the full path to libraries
>>> thus not to need to use "LINK_DIRECTORIES".
>>
>> You are right. It seems that removing LINK_DIRECTORIES does the trick!
>
> Oops... My bad. Nope, CMake still does not find the OpenSSL library, even if I
> throw all INCLUDE and LINK directories directives away...
>
> Is there a way to trace what CMake is doing when looking up for OpenSSL?

man page told me about --trace...

After some intensive digging, I think I have found the problem. My rootfs has
broken links, in particular for libssl.so and libcrypto.so ... So no wonder that
CMake got troubled..

I'll correct those and let you know.

Thanks a lot for you help,
Loïc
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake toolchain and FIND_PACKAGE(OpenSSL)

[Boards Killer]

>> I'm pretty sure LINK_DIRECTORIES should not be used in toolchain
>> if not use at all.
>>
>> The purpose of find_package is precisely to find the full path to libraries
>> thus not to need to use "LINK_DIRECTORIES".
>
> You are right. It seems that removing LINK_DIRECTORIES does the trick!

Oops... My bad. Nope, CMake still does not find the OpenSSL library, even if I
throw all INCLUDE and LINK directories directives away...

Is there a way to trace what CMake is doing when looking up for OpenSSL?

TIA,
/ld
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake toolchain and FIND_PACKAGE(OpenSSL)

[Boards Killer]

Hi Vyacheslav,
Salut Eric,

Many thanks for your answers.

>> I thought that adding a LINK_DIRECTORIES to the toolchain would do the
>> trick, but no avail.
>
> I'm pretty sure LINK_DIRECTORIES should not be used in toolchain
> if not use at all.
>
> The purpose of find_package is precisely to find the full path to libraries
> thus not to need to use "LINK_DIRECTORIES".

You are right. It seems that removing LINK_DIRECTORIES does the trick!


>> What is the best way to tell CMake where to find the libraries? Should I set
>> the path manually in the toolchain, for instance.
>
> Nope. you shoud throw away
> INCLUDE_DIRECTORIES
> and
> LINK_DIRECTORIES
> from your toolchain

If I throw the INCLUDE_DIRECTORIES directives way, CMake runs fine but the
project fails to compile. If I leave the (1st) INCLUDE_DIRECTORIES directive,
then every "works" as expected.

The only difference between both versions, is in the latter the flag -isystem
is passed to the compiler. That seems to make a huge difference at the end.

Of course, if there is a more sensible way do achieve the same result, I'd glad
to "ear" it.


> By the way, which version of CMake are you using?

Sorry, I forgot to mention the obvious. I am using CMake 2.8.3.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake toolchain and FIND_PACKAGE(OpenSSL)

[Eric Noulard]

2012/11/19 Boards Killer :
> Hi CMake Community !
>
> I am writing a CMake toolchain to cross compile our CMake project with the
> Ubuntu ARM Linux toolchain. The CMake toolchain is given below.
>
> I am facing the following problem. When using:
> FIND_PACKAGE(OpenSSL)
>
> The libraries (lssl, lcrypto) are *not* found. There are actually located at
> $ENV{SDK_TARGET}/lib
>
> I thought that adding a LINK_DIRECTORIES to the toolchain would do the
> trick, but no avail.

I'm pretty sure LINK_DIRECTORIES should not be used in toolchain
if not use at all.

The purpose of find_package is precisely to find the full path to libraries
thus not to need to use "LINK_DIRECTORIES".

> What is the best way to tell CMake where to find the libraries? Should I set
> the path manually in the toolchain, for instance.

Nope. you shoud throw away
INCLUDE_DIRECTORIES
and
LINK_DIRECTORIES
from your toolchain

and then retry in order to see what happen with find_package(OpenSSL)
proper setting of

CMAKE_FIND_ROOT_PATH* should makes it possible for FindOpenSSL to find
the lib.

By the way, which version of CMake are you using?
-- 
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CMake toolchain and FIND_PACKAGE(OpenSSL)

[Vyacheslav Karamov]

Hi, try setting

packagename_DIR before FIND_PACKAGE()

19.11.2012 14:41, Boards Killer ?:

Hi CMake Community !

I am writing a CMake toolchain to cross compile our CMake project with 
the Ubuntu ARM Linux toolchain. The CMake toolchain is given below.


I am facing the following problem. When using:
FIND_PACKAGE(OpenSSL)

The libraries (lssl, lcrypto) are *not* found. There are actually 
located at

$ENV{SDK_TARGET}/lib

I thought that adding a LINK_DIRECTORIES to the toolchain would do the 
trick, but no avail.


What is the best way to tell CMake where to find the libraries? Should 
I set the path manually

in the toolchain, for instance.

TIA,
/ld
--
# Cmake toolchain for cross compiling

# target system type
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
SET(CMAKE_SYSTEM_PROCESSOR armv7l)

INCLUDE_DIRECTORIES(SYSTEM "$ENV{SDK_TARGET}/usr/include")
INCLUDE_DIRECTORIES(SYSTEM 
"$ENV{SDK_TARGET}/usr/include/arm-linux-gnueabi")

LINK_DIRECTORIES("$ENV{SDK_TARGET}/lib")

# specify the cross compiler
SET(CMAKE_C_COMPILER   arm-linux-gnueabi-gcc)
SET(CMAKE_CXX_COMPILER arm-linux-gnueabi-g++)

# location of target environment
SET(CMAKE_FIND_ROOT_PATH $ENV{SDK_TARGET})

# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)



--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Building OpenCV with TI cl6x compiler using cmake toolchain file

[Antje Kühn]

Hi,

 

I want to build the opencv lib with the cl6x compile for a dsp platform
under linux.

For that I use the following toolchain file:

 

set(CMAKE_SYSTEM_NAME Linux )

set(DVSDK_HOME /home/developer/ti-dvsdk_omapl138-evm_04_02_00_06)

SET(CMAKE_FIND_ROOT_PATH ${DVSDK_HOME}/cgt6x_6_1_14)

set(CMAKE_C_COMPILER ${DVSDK_HOME}/cgt6x_6_1_14/bin/cl6x)

set(CMAKE_STRIP ${DVSDK_HOME}/cgt6x_6_1_14/bin/strip6x)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)

set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

set(CMAKE_C_LINK_EXECUTABLE "${DVSDK_HOME}/cgt6x_6_1_14/bin/cl6x -g -d_DEBUG
-q -ml3 -mv6740 -rtti -I${DVSDK_HOME}/cgt6x_6_1_14/include
-I${DVSDK_HOME}/cgt6x_6_1_14/lib")

 

 

And this is the error message:

 

-- The C compiler identification is TI_DSP

-- The CXX compiler identification is GNU 4.4.3

-- Check for working C compiler:
/home/developer/ti-dvsdk_omapl138-evm_04_02_00_06/cgt6x_6_1_14/bin/cl6x

-- Check for working C compiler:
/home/developer/ti-dvsdk_omapl138-evm_04_02_00_06/cgt6x_6_1_14/bin/cl6x --
works

-- Detecting C compiler ABI info

CMake Error at
/usr/local/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:31
(TRY_COMPILE):

  Cannot copy output executable

 

''

 

  to destination specified by COPY_FILE:

 

 
'/home/developer/OpenCV-2.3.1/build/CMakeFiles/CMakeDetermineCompilerABI_C.b
in'

 

  Unable to find the executable at any of:

 

 
/home/developer/OpenCV-2.3.1/build/CMakeFiles/CMakeTmp/cmTryCompileExec26378
97029

 
/home/developer/OpenCV-2.3.1/build/CMakeFiles/CMakeTmp/Debug/cmTryCompileExe
c2637897029

 
/home/developer/OpenCV-2.3.1/build/CMakeFiles/CMakeTmp/Development/cmTryComp
ileExec2637897029

 

Call Stack (most recent call first):

  /usr/local/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:71
(CMAKE_DETERMINE_COMPILER_ABI)

  CMakeLists.txt:40 (project)

 

 

-- Detecting C compiler ABI info - done

CMake Error at
/usr/local/share/cmake-2.8/Modules/CMakeDetermineCompilerABI.cmake:48
(FILE):

  file STRINGS file

 
"/home/developer/OpenCV-2.3.1/build/CMakeFiles/CMakeDetermineCompilerABI_C.b
in"

  cannot be read.

Call Stack (most recent call first):

  /usr/local/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:71
(CMAKE_DETERMINE_COMPILER_ABI)

  CMakeLists.txt:40 (project)

 

 

Has anyone an idea?

 

Thanks

Antje

 

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] toolchain file and initial cache

[Alexander Neundorf]

On Tuesday 13 December 2011, Tom Deblauwe wrote:
> Hello,
> 
> I have a question: Using the -C option you can specify an initial cache
> file. I have this case where I like to specify some initial cache
> values, but also a toolchain file. Can I combine this and add a line in
> the initial cache file:
> 
> set(CMAKE_TOOLCHAIN_FILE "toolchain.cmake" CACHE PATH "Toolchain file")
> 
> Will this work the same?

I haven't tried, but I think this should work.

You can check in the build whether CMAKE_SYSTEM_NAME and CMAKE_CROSSCOMPILING 
are set as you expect, if so, everything should be fine.

Alex
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] toolchain file and initial cache

[Tom Deblauwe]

Hello,

I have a question: Using the -C option you can specify an initial cache 
file. I have this case where I like to specify some initial cache 
values, but also a toolchain file. Can I combine this and add a line in 
the initial cache file:


set(CMAKE_TOOLCHAIN_FILE "toolchain.cmake" CACHE PATH "Toolchain file")

Will this work the same?
Best regards,
Tom

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] ToolChain file scope

[Kishore]

On Tuesday 07 Jun 2011 7:40:33 PM dfurt...@cox.net wrote:
> I have been hammergin on a vxworks cross-compile toolchain file. It seems
> that not all properties that are set in the cross-compilation file
> propogate to the CMakeLists.txt file that is using it. An example is the
> CMAKE_AR property.  Setting it in the cross-compilation file had no effect
> and the value during linking of a static library was "'. Once I moved it to
> the CMakeLists.txt file the setting was recognized. Setting of library
> prefix and postfix values seemed to behave the same way.
> 
> These things seem like reasonable targets for the cross-compilation file so
> I am confused as to why they wouldn't work. Any help is appreciated.

I would be interested in this information too. Too often i get bitten by the 
scope issues when working with "Generic" embedded systems. In addition, I 
would also like the scope of the three platform/* modules to be documented as 
well.
-- 
Cheers!
Kishore
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] ToolChain file scope

[dfurtney]

I have been hammergin on a vxworks cross-compile toolchain file. It seems that 
not all properties that are set in the cross-compilation file propogate to the 
CMakeLists.txt file that is using it. An example is the CMAKE_AR property.  
Setting it in the cross-compilation file had no effect and the value during 
linking of a static library was "'. Once I moved it to the CMakeLists.txt file 
the setting was recognized. Setting of library prefix and postfix values seemed 
to behave the same way.

These things seem like reasonable targets for the cross-compilation file so I 
am confused as to why they wouldn't work. Any help is appreciated.

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Toolchain changes even though specified on the command line

[J Decker]

I have several compilers setup on my box for various reasons.

I definately know this shows up when building for mingw and using the
wrong command prompt with say visual studio in the path, and gcc not
in the path.

First, I create a new build output directory go into that directory
and run a command line that specifies -G "MinGW Makefiles"..  then
run 'make install' and of course the project builds;  and I keep this
around for  a long time and keep revisiting, every time running the
full cmake command line specifying all the parameters I want to use;
it looks something like this

'cmake -G "MinGW Makefiles"  /sack -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_INSTALL_PREFIX=/build/mingw_mono32_sack_core -DNEED_FREETYPE=1
-DNEED_JPEG=1 -DNEED_PNG=1 -DNEED_ZLIB=1 -DBUILD_MONOLITHIC=1'

Then in a command shell that has watcom as the environment; it has
tools 'nmake' and 'cl' etc which are supposedly clones of microsoft
for compatiblity.

the following is the output

M:\build\mingw\sack\mono32_core>cmake -G "MinGW Makefiles"  /sack
-DCMAKE_BUILD_TYPE=Debug
-DCMAKE_INSTALL_PREFIX=/build/mingw_mono32_sack_core -DNEED_FREETYPE=1
-DNEED_JPEG=1 -DNEED_PNG=1 -DNEED_ZLIB=1 DBUILD_MONOLITHIC=1
CMake Error: your RC compiler: "windres" was not found.   Please set
CMAKE_RC_COMPILER to a valid compiler path or name.
-- Configuring incomplete, errors occurred!
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_RC_COMPILER= c:/tools/unix/mingw/bin/windres.exe

-- Generating done
-- Build files have been written to: M:/build/mingw/sack/mono32_core


M:\build\mingw\sack\mono32_core>make install
-- Building for: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10
-- Check for working C compiler using: Visual Studio 10 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 10...


So now I realize my mistake and hit ctrl-C and go to the correct shell
but now when I run the build process I get




M:\build\mingw\sack\mono32_core>cmake -G "MinGW Makefiles"  /sack
-DCMAKE_BUILD_TYPE=Debug
DCMAKE_INSTALL_PREFIX=/build/mingw_mono32_sack_core -DNEED_FREETYPE=1
-DNEED_JPEG=1 -DNEED_PNG=1 -DNEED_ZLIB=1 DBUILD_MONOLITHIC=1
CMake Error: Error: generator : MinGW Makefiles
Does not match the generator used previously: Visual Studio 10
Either remove the CMakeCache.txt file or choose a different binary directory.

M:\build\mingw\sack\mono32_core>make install
... 1
-- Configuring done
-- Generating done
-- Build files have been written to: M:/build/mingw/sack/mono32_core
Scanning dependencies of target sack_bag
CMake Error: Directory Information file not found
[  1%] Building C object
CMakeFiles/sack_bag.dir/src/deadstart/deadstart_list.c.obj
'""' is not recognized as an internal or external command,
operable program or batch file.
make[2]: *** [CMakeFiles/sack_bag.dir/src/deadstart/deadstart_list.c.obj]
Error 1
make[1]: *** [CMakeFiles/sack_bag.dir/all] Error 2
make: *** [all] Error 2

--- So even though the makefiles were created with mingw, the
cache got deleted because it can't find 'windres'; and is now allowed
to configure for a different compiler than what was specified on the
command line.  I have to manually delete the CMakeCache.txt and start
over; which causes a recompilation of the entire project.

Maybe if the makefile output included the generator so it wouldn't
just invoke cmake with no generator, allwoing cmake to choose an
inappropriate generator for the output that already exists?  I do note
that since 'windres.exe' doesn't exist cmake deletes the
CMakeCache.txt; maybe if it just didn't do that?
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] "Toolchain" for native builds

[Will Dicharry]

Adolfo Rodríguez wrote:

One alternative that comes into my mind would be to invoke cmake like

cmake -C initialCache.cmake
where initialCache.cmake is a script that preloads a set of cache 
variables, i.e., with entries like

set(CMAKE_CXX_COMPILER icpc CACHE STRING "CXX compiler." FORCE)

Would this accomplish what you want?



Thank you for the solution! I think that would accomplish what I am 
going for in most cases.  The only problem I see with that approach (and 
it's a small problem that I'm willing to deal with) is the difference in 
build procedure between cross-compiling and non cross-compiling 
environments.  Actually, will the initial cache work properly with 
cross-compiling if I set CMAKE_TOOLCHAIN_FILE in the initial cache 
file?  If that will work, then I think this solution will work just fine 
for our needs.


Thanks again,
Will


Adolfo.

On Fri, Jul 10, 2009 at 1:06 AM, S. Levent Yilmaz 
mailto:leventyil...@gmail.com>> wrote:


This question was asked a while
ago:http://www.cmake.org/pipermail/cmake/2009-June/030404.html with
no definitive answer.. 


So, I'll try to raise this issue from a different angle, perhaps
this will make more sense to the developers. 


Take a look at this line:

cmake \
   -DCMAKE_CXX_COMPILER=icpc \
   -DCMAKE_C_COMPILER=icc \
   -DCMAKE_Fortran_COMPILER=ifort \
   -DCMAKE_CXX_FLAGS_RELWITHDEBINFO='-O2 -g -debug
inline-debug-info'  \
   -DCMAKE_C_FLAGS_RELWITHDEBINFO='-O2 -g -debug inline-debug-info'  \
   -DCMAKE_Fortran_FLAGS_RELWITHDEBINFO='-O2 -g -debug
inline-debug-info'  \
   -DBLA_VENDOR=Intel \
   -DBLA_BLA \
   /path/to/source

Now, the thing I want to emphasize about this "configuration" line
is that the settings are not specific to a given project. It just
"activates" a custom compiler suite. Another perfectly reasonable
scenario is further refinements made for specific platforms.
And, really, compilation being cross or native is an orthogonal
issue here. 

The earlier dialog was: 


>> [Will Dicharry wrote:]

>> Am I misusing the toolchain file capability?

> [Bill Hoffman wrote:]

> Yes, that should only be used for cross-compiling.

> To set the compilers you can set the environment variables
FC, CC, and CXX before running CMake.


So, now my question is, how can I reduce the above cmake configure
line muddied with plethora of compiler (and/or platform) specific
definitions (or preceding environment variables for that matter) into:

cmake
-DCMAKE_OK_NOT_TOOLCHAIN_BUT_WHAT_FILE=site/macros/intel.cmake
/path/to/source

? 


Levent

___
Powered by www.kitware.com 

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake




--
Adolfo Rodríguez Tsouroukdissian

Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, 
pueden contener información privilegiada y/o confidencial que está 
dirigida exclusivamente a su destinatario. Si usted recibe este 
mensaje y no es el destinatario indicado, o el empleado encargado de 
su entrega a dicha persona, por favor, notifíquelo inmediatamente y 
remita el mensaje original a la dirección de correo electrónico 
indicada. Cualquier copia, uso o distribución no autorizados de esta 
comunicación queda estrictamente prohibida.


CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) 
may contain confidential information which is privileged and intended 
only for the individual or entity to whom they are addressed.  If you 
are not the intended recipient, you are hereby notified that any 
disclosure, copying, distribution or use of this e-mail and/or 
accompanying document(s) is strictly prohibited.  If you have received 
this e-mail in error, please immediately notify the sender at the 
above e-mail address.



___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake





smime.p7s
Description: S/MIME Cryptographic Signature
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check

Re: [CMake] "Toolchain" for native builds

[Adolfo Rodríguez]

One alternative that comes into my mind would be to invoke cmake like

cmake -C initialCache.cmake

where initialCache.cmake is a script that preloads a set of cache variables,
i.e., with entries like
set(CMAKE_CXX_COMPILER icpc CACHE STRING "CXX compiler." FORCE)

Would this accomplish what you want?

Adolfo.

On Fri, Jul 10, 2009 at 1:06 AM, S. Levent Yilmaz wrote:

> This question was asked a while ago:
> http://www.cmake.org/pipermail/cmake/2009-June/030404.html with no
> definitive answer..
> So, I'll try to raise this issue from a different angle, perhaps this will
> make more sense to the developers.
>
> Take a look at this line:
>
> cmake \
>-DCMAKE_CXX_COMPILER=icpc \
>-DCMAKE_C_COMPILER=icc \
>-DCMAKE_Fortran_COMPILER=ifort \
>-DCMAKE_CXX_FLAGS_RELWITHDEBINFO='-O2 -g -debug inline-debug-info'  \
>-DCMAKE_C_FLAGS_RELWITHDEBINFO='-O2 -g -debug inline-debug-info'  \
>-DCMAKE_Fortran_FLAGS_RELWITHDEBINFO='-O2 -g -debug inline-debug-info'
>  \
>-DBLA_VENDOR=Intel \
>-DBLA_BLA \
>/path/to/source
>
> Now, the thing I want to emphasize about this "configuration" line is that
> the settings are not specific to a given project. It just "activates" a
> custom compiler suite. Another perfectly reasonable scenario is further
> refinements made for specific platforms. And, really, compilation being
> cross or native is an orthogonal issue here.
>
> The earlier dialog was:
>
> >> [Will Dicharry wrote:]
>
> >> Am I misusing the toolchain file capability?
>
> > [Bill Hoffman wrote:]
>
> > Yes, that should only be used for cross-compiling.
>
> > To set the compilers you can set the environment variables FC, CC,
>> and CXX before running CMake.
>
>
> So, now my question is, how can I reduce the above cmake configure line
> muddied with plethora of compiler (and/or platform) specific definitions (or
> preceding environment variables for that matter) into:
>
> cmake -DCMAKE_OK_NOT_TOOLCHAIN_BUT_WHAT_FILE=site/macros/intel.cmake
> /path/to/source
>
> ?
>
> Levent
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



-- 
Adolfo Rodríguez Tsouroukdissian

Robotics engineer
PAL ROBOTICS S.L
http://www.pal-robotics.com
Tel. +34.93.414.53.47
Fax.+34.93.209.11.09
AVISO DE CONFIDENCIALIDAD: Este mensaje y sus documentos adjuntos, pueden
contener información privilegiada y/o confidencial que está dirigida
exclusivamente a su destinatario. Si usted recibe este mensaje y no es el
destinatario indicado, o el empleado encargado de su entrega a dicha
persona, por favor, notifíquelo inmediatamente y remita el mensaje original
a la dirección de correo electrónico indicada. Cualquier copia, uso o
distribución no autorizados de esta comunicación queda estrictamente
prohibida.

CONFIDENTIALITY NOTICE: This e-mail and the accompanying document(s) may
contain confidential information which is privileged and intended only for
the individual or entity to whom they are addressed.  If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution or use of this e-mail and/or accompanying document(s) is
strictly prohibited.  If you have received this e-mail in error, please
immediately notify the sender at the above e-mail address.
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] "Toolchain" for native builds

[S. Levent Yilmaz]

This question was asked a while ago:
http://www.cmake.org/pipermail/cmake/2009-June/030404.html with no
definitive answer..
So, I'll try to raise this issue from a different angle, perhaps this will
make more sense to the developers.

Take a look at this line:

cmake \
   -DCMAKE_CXX_COMPILER=icpc \
   -DCMAKE_C_COMPILER=icc \
   -DCMAKE_Fortran_COMPILER=ifort \
   -DCMAKE_CXX_FLAGS_RELWITHDEBINFO='-O2 -g -debug inline-debug-info'  \
   -DCMAKE_C_FLAGS_RELWITHDEBINFO='-O2 -g -debug inline-debug-info'  \
   -DCMAKE_Fortran_FLAGS_RELWITHDEBINFO='-O2 -g -debug inline-debug-info'  \
   -DBLA_VENDOR=Intel \
   -DBLA_BLA \
   /path/to/source

Now, the thing I want to emphasize about this "configuration" line is that
the settings are not specific to a given project. It just "activates" a
custom compiler suite. Another perfectly reasonable scenario is further
refinements made for specific platforms. And, really, compilation being
cross or native is an orthogonal issue here.

The earlier dialog was:

>> [Will Dicharry wrote:]

>> Am I misusing the toolchain file capability?

> [Bill Hoffman wrote:]

> Yes, that should only be used for cross-compiling.

> To set the compilers you can set the environment variables FC, CC, and CXX
> before running CMake.


So, now my question is, how can I reduce the above cmake configure line
muddied with plethora of compiler (and/or platform) specific definitions (or
preceding environment variables for that matter) into:

cmake -DCMAKE_OK_NOT_TOOLCHAIN_BUT_WHAT_FILE=site/macros/intel.cmake
/path/to/source

?

Levent
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] toolchain files ADD_DEFINITIONS interpreted multiply

[Frans.Fuerst]

And again..
 
I moved an ADD_DEFINITIONS instruction to my symbian toolchain file:
 
ADD_DEFINITIONS(-include 
"\"C:/Symbian/9.2/S60_3rd_FP1/EPOC32/INCLUDE/GCCE/GCCE.h\"" )
 
now the include flag is added twice to the compiler command even after deleting 
every intermediately generated cache file multiple times. This leads to several 
redefinitions..
 
Obviously gcce.h should be embraced in macros properly. But is that behaviour 
intended?
 
hth,
Frans
 



Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake