Re: [CMake] XMOS ASM / C Compiler support progress and questions
Hi Alexander,
2011/10/12 Alexander Neundorf :
> Hi,
>
> On Wednesday 12 October 2011, Bernhard Sputh wrote:
> Cool :-)
> Please create an entry in the bug tracker for that, so it doesn't get lost.
OK, will do this later today.
> Since 2.8.5 the "ASM" language is the one to use for assembler files which are
> processed by the C or C++ compiler, i.e. which may need to be preprocessed.
> I.e. you shouldn't even have to set CMAKE_ASM_COMPILER, when enabling ASM it
> will use the value of CMAKE_C_COMPILER for CMAKE_ASM_COMPILER.
Ah good to know.
> Why do you set the compiler id to GNU ?
> That's not a good idea I'd say.
The XMOS toolchain has for the basic functions compatible command line
switches to the GNU toolchain. However, it's not based on GNU
directly, but is based on LLVM [1] instead.
>> I would prefer to not to have not force the compiler, but the recent
>> XMOS toolchain require an additional command line argument to specify
>> the processor to compile for: `-target'. As far as I'm aware there is
>> no way to pass additional compiler flags to the compiler checking
>> operations.
>
> How does the syntax look exactly ?
>
> xcc -target Foo
> or
> xcc -target=Foo ...
> ?
>
> In the second case, it should work if you do
> set(CMAKE_C_COMPILER xcc -target=Foo)
Thank you for that hint, it will be useful in the future.
To be precise there are two forms, one where one uses the from:
- `-target=XC-1': To select the XC-1 development board.
- `${PATH}/${System}.xn': To specify a custom topology which consists
of one or multiple CPU-Cores and their IO.
I'll have to experiment here a little bit, and maybe get in touch with
XMOS regarding this. Their previous versions of the toolchain (before
version 10.x) could work without this option. This is not sufficient
when compiling and linking for real systems, but more than sufficient
to check whether or not the compiler works.
Cheers
Bernhard
[1] http://llvm.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
[CMake] XMOS ASM / C Compiler support progress and questions
Hi List,
I'm currently working on better integrating the XMOS toolchain [1]
(version 11.2.2) into CMake 2.8.5, among other things (such as TI
C6000 support). I've today managed to integrate the detection of the
XMOS assembler. Basically, all I had to do is to insert these three
lines in the file CMakeDetermingASMCompiler.cmake (find my modified
version attached, feel free to include in future versions):
LIST(APPEND CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDORS XMOS )
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_FLAGS_XMOS "--version")
SET(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_XMOS "XMOS Limited")
Furthermore, the file XMOS-ASM.cmake (attached, may be included as
well) has to be added to Modules/Compilers/. In this file the valid
extensions get set, which in our case are xc (special language from
XMOS to program their CPUs), s and S. I'm cheating a bit when
specifying the assembler executable because I use xcc instead of xas,
but this is necessary in order to get the xc-files processed
correctly. I'll clean this up at one point, but this workaround has
worked for us the past two years, and nothing lasts longer than a
working workaround.
The toolchain file to use looks as follows:
SET(CMAKE_SYSTEM_VERSION 2.8)
INCLUDE(CMakeForceCompiler)
SET(CMAKE_SYSTEM_NAME generic)
CMAKE_FORCE_C_COMPILER(xcc GNU)
CMAKE_FORCE_CXX_COMPILER(xcc GNU)
SET(CMAKE_COMPILER_IS_GNUCXX 1)
SET(CMAKE_ASM_COMPILER "xcc")
I would prefer to not to have not force the compiler, but the recent
XMOS toolchain require an additional command line argument to specify
the processor to compile for: `-target'. As far as I'm aware there is
no way to pass additional compiler flags to the compiler checking
operations.
Cheers
Bernhard
[1] https://www.xmos.com/products/development-tools
XMOS-ASM.cmake
Description: Binary data
CMakeDetermineASMCompiler.cmake
Description: Binary data
--
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] Thoughts on Cross-compiling with CMake
Hi Alexander,
On Monday 30 April 2007 13:50, Alexander Neundorf wrote:
> Yes, we'll do so (/me being a cmake developer for the next few months) :-)
> I'm starting to add cross compiling support to cmake right now and will
> reuse the patches in the next days.
> The first step will be to let the user specify the compiler/target platform
> he wants to build for without the cmake automatic detection. This will
> require almost only changes in the script files.
Thank You for working on this. I have another suggestion related to
cross-compilation. It should be possible to provide Compiler / Environment
scripts with ones project. These scripts could be located for instance in a
directory called `${CMAKE_SOURCE_DIR}/CMake_Platform/' or similar. This way a
cross-compilation project could be distributed without the need to include a,
potentially non-working, patch to the CMake scripts.
Cheers
Bernhard
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Thoughts on Cross-compiling with CMake
Trevor, thank You for the patches You attached. On Sunday 29 April 2007 18:00, Trevor Kellaway wrote: > I was trying not to modify CMake source, given it nicely uses scripts > that are easy to change, and more accessible to most people. Yes, and I think You are right with this approach. > Patches attached, against 2.4p6 release, but patches created against my > Subversion base copy of CMake (sorry): Should not be a major problem, I will read them and then maybe modify / extend them to work with the specific setup I'm having here. > Note that GenericBuildPrologue.cmake does some nasty non-standard things > to CMAKE_BUILD_TYPE (via GENERIC_BUILD_TYPE), setting the style of build > based on the output directory name, this is because our existing build > system which I'm porting does this. This is *not* the correct CMake way > of doing things. OK, that is good to know for when I try to port the current hack to compile XMK (Xilinx Microkernel) code into proper CMake code. > Nope, mainly because I don't know how to. This project seems unlike > others that actively publish bleeding edge builds, all I've found is the > main CVS tree (I use Subversion) and this forum, I assume the developers > hang out here? I too think that the developers are actively reading this list, maybe they can utilise Your patches for the next version. > CMake is very good once you start to get the hang of it, but it can be > an uphill struggle with the lack of documentation at times, which could > well put people off. I agree, but the GNU autotools, are not easy to use either, and I found them even harder to use. Cheers Bernhard ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Thoughts on Cross-compiling with CMake
Trevor, On Sunday 29 April 2007 09:59, Trevor Kellaway wrote: > Which bug ID? That would be ID 14, opened in 2003 and set on low priority, well very low it seems to me. > Have a look at this thread > http://public.kitware.com/pipermail/cmake/2007-March/013083.html This thread must have slipped my radar, it looks very similar to what I was thinking of. Except that my idea was to modify the behaviour of the CMake's source code, while Your solution relies on simply modifying the scripts CMake uses. > I'm using this approach to build multiple targets, for embedded > processors with multiple compilers (and for the PC as well). > > I can post the patches if you like. Thank You, that would be helpful, even if I learnt a lot from the snippets You sent in Your earlier post. BTW, have You submitted the patches to the development team? Cheers Bernhard ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Thoughts on Cross-compiling with CMake
I'm subscribed to this mailing list for the past few month and it has helped me a lot in the past, just reading the posts. What I can detect is that there seems to be a constant demand for cross-compilation support for CMake. According to the bug tracking system entry [1] some one is working on this feature already, which is good. The reason for this post is that I've spent the past few days fighting against / with CMake to compile a project for an embedded system (a PowerPC CPU running Xilinx Microkernel as OS, using GCC supplied by Xilinx). What I can say, yes I got it to compile using Linux, but only by tricking CMake not to check for the real compilers to use, but by letting it find the standard GCC tools. I was unsuccessful with my tries to get the same software package to compile under CYGWIN. This is caused by the fact that CMake tries to use CYGWIN specific command line parameters for the compiler (iirc – set-image-major-version,1 or similar) which the correctly called Xilinx compiler and linker refused to accept and then aborts. I have tried to change these command line parameters within my project build script but this did not work. Therefore, I took a look at the source code trying to understand why it was not possible for me to set the correct command line parameters. This revealed that CMake always does an automatic determination of the OS and tests the compiler once it comes across: `PROJECT(foo)'. Previous set values for the correct command line parameters are ignored. While this behaviour is nearly ideal for normal compilation, i.e. not cross-compilation, it hinders cross compilation, and a way to disable it is nearly all that is necessary, to at least get my code to compile. However, this would be very short sighted, so in the remainder of this email I want to present my ideas on how cross-compilation support could be implemented in CMake, to start a discussion on the subject, which hopefully leads to a good implementation. 1.)Make the auto detection of OS and compiler command line parameters in `PROJECT(foo)' optional. This means CMake should not overwrite these settings when the user specified them earlier. 2.)Allow users to specify for which OS they want their project to be build. My idea how to do this would be to set a variable, for instance called `TARGET_OS=bar'. This would then evaluated by the command PROJECT(foo) and the corresponding parameter file would then be loaded, specifying all variables. The advantage of this is that the already existing OS definition files could be reused. If no such file is found within the CMake distribution directories, CMake should scan the project main directory, and the module directories. 3.)Similarly the user should be permitted to define the CPU to compile for, without tweaking with an environment variable (CC). The reason for this is that I have a project where I need to compile the same library once for a Microblaze processor and then for a PowerPC processor. To tweak a global variable is not nice in this scenario. Of course one could go over a script, but I think it is more user friendly to let the user pass a command line variable, for instance `-DTARGET_CC=baz-gcc' (same for other compilers). Even nicer because it is more generic, but much more difficult to implement would be `-DTARGET_CPU=baz' and CMake determines which tool-chain to use automatically. This determination could be aided by files where the developer defines which compiler to use on which platform. These are my thoughts on how CMake support for cross-compilation could / should look like. But I have to admit I'm no CMake expert, just a user of it. So what do others think of these suggestions, and more importantly what do the CMake developers think of them? Cheers Bernhard Sputh [1] http://www.cmake.org/Bug/bug.php?op=show&bugid=14&pos=1 -- "Real programmers can write assembly code in any language." - Larry Wall ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
