headers
Kishore, Jonnalagadda (IE10 | 1 Mar 2007 07:26
Picon
Favicon

crosscompiling problems on XP

I have recently tried porting a project to CMake but I am facing a few issues when cross-compiling

The project can be compiled with a varying set of compilers (already works with our custom makefiles) and
currently the only option seems to be passing this information along with the cmake command. This fails
with different errors when executed from within the cygwin shell or the windows command prompt.

I am doing a simple test with just two files.

main.c:
	main()
	{
	}

CMakeLists.txt:
	PROJECT(test)
	ADD_EXECUTABLE(test main.c)

In the cygwin shell I get;
$ cmake -DCMAKE_C_COMPILER=avr-gcc -DCMAKE_CXX_COMPILER=avr-g++ -G "Unix Makefi
les" .
-- Check for working C compiler: avr-gcc
-- Check for working C compiler: avr-gcc -- broken
CMake Error: The C compiler "avr-gcc" is not able to compile a simple test progr
am.
It fails with the following output:
 make: Warning: File `CMakeFiles/progress.make' has modification time 0.24 s in
the future
/usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make CMakeFiles/cmTryComp
ileExec.dir/build
make[1]: Entering directory `/cygdrive/e/temp/cmake_test/CMakeFiles/CMakeTmp'
(Continue reading)

Permalink | Reply | 4 comments |
headers
Timo Rumland | 1 Mar 2007 15:25
Picon

Creating some kind of release target

Hello,

I recently created a new buildsystem for our project with CMake, and I
like it much.

Now I have to do some kind of release target, so we can pack a release
version of our project for distributing it over sourceforge.

What I need is a new build target named "release", when I build this
("make release" or building the target "release" in Visual Studio),
all the sources will be zipped/tar.gz, so we can easily upload it to
sourceforge.

Is this possible with CMake? Or is there another way how it's usually
done?

Thanks a lot for your help

Timo
Permalink | Reply | 5 comments |
headers
Eric Noulard | 1 Mar 2007 15:59
Picon

Re: Creating some kind of release target

2007/3/1, Timo Rumland <cr@...>:
> Hello,
>
> I recently created a new buildsystem for our project with CMake, and I
> like it much.
>
> Now I have to do some kind of release target, so we can pack a release
> version of our project for distributing it over sourceforge.
>
> What I need is a new build target named "release", when I build this
> ("make release" or building the target "release" in Visual Studio),
> all the sources will be zipped/tar.gz, so we can easily upload it to
> sourceforge.

You may use CPack for this need.
Look at:
http://www.cmake.org/Wiki/CMake:Packaging_With_CPack

--

-- 
Erk
Permalink | Reply | 0 comments |
headers
Alan W. Irwin | 1 Mar 2007 17:04
Picon
Picon

Re: Creating some kind of release target

On 2007-03-01 15:25+0100 Timo Rumland wrote:

> Hello,
>
> I recently created a new buildsystem for our project with CMake, and I
> like it much.
>
> Now I have to do some kind of release target, so we can pack a release
> version of our project for distributing it over sourceforge.
>
> What I need is a new build target named "release", when I build this
> ("make release" or building the target "release" in Visual Studio),
> all the sources will be zipped/tar.gz, so we can easily upload it to
> sourceforge.
>
> Is this possible with CMake? Or is there another way how it's usually
> done?

Both source and binary releases are possible with the companion cpack
programme which you can configure via cmake.  For fundamental information
see http://www.cmake.org/Wiki/CMake:Packaging_With_CPack.  For a working
example, see the top-level CMakeLists.txt file from the CMake software
itself (or the PLplot software).  After such a cmake setup, then you create a
source release and binary release with the

make package_source

and

make package
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kent Boortz | 2 Mar 2007 02:58
Picon
Favicon

Is HAVE_LOCALE_H patch correct?


Hi,

I could not compile released "cmake-2.4.6" on several platforms

 Fedora Core 4 x86
 FreeBSD 6 x86 and x86_64
 Red Hat RHAS 4 x86 and x86_64
 SuSE SLES9 x86 and x86_64
 SuSE 7.3 x86

The error message is

  Source/CursesDialog/form/fty_num.c: In function `Check_Numeric_Field':
  Source/CursesDialog/form/fty_num.c:124: error: `L' undeclared (first use in this function)
  Source/CursesDialog/form/fty_num.c:124: error: (Each undeclared identifier is reported only once
  Source/CursesDialog/form/fty_num.c:124: error: for each function it appears in.)
  Source/CursesDialog/form/fty_num.c: In function `Check_Numeric_Character':
  Source/CursesDialog/form/fty_num.c:170: error: `L' undeclared (first use in this function)

To me it looks like incomplete coding when HAVE_LOCALE_H is set. Could
you please confirm that the following patch is correct?

  --- Source/CursesDialog/form/fty_num.c.ORIG     2007-03-02 02:28:33.065531923 +0100
  +++ Source/CursesDialog/form/fty_num.c  2007-03-02 02:32:55.095895314 +0100
   <at>  <at>  -23,7 +23,9  <at>  <at> 
     int    precision;
     double low;
     double high;
  +#if HAVE_LOCALE_H
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kent Boortz | 2 Mar 2007 03:13
Picon
Favicon

Problem building 2.4.6 on AIX using xlr_c 6


Hi,

I could not compile released "cmake-2.4.6" on AIX 5.2 using xlr_c
6.0.0. The problem is that some headers are included first and later
"zconf.h" that will in this setup do

  #define const

This will in effect remove all const declarations after this point.
The compile continues with defining the fuctions and then detect that
the declaration and definition doesn't match. The error message is a
bit strange (there is no explicit "unsigned" in the source), likely a
small flaw in the compiler

  "Utilities/cmcurl/strerror.c", line 45.1: 1506-343 (S) Redeclaration of curl_easy_strerror differs
from previous declaration on line 1318 of "Utilities/cmcurl/curl/curl.h".
  "Utilities/cmcurl/strerror.c", line 45.1: 1506-050 (I) Return type "unsigned char*" in redeclaration
is not compatible with the previous return type "const unsigned char*".
  "Utilities/cmcurl/strerror.c", line 254.1: 1506-343 (S) Redeclaration of curl_multi_strerror
differs from previous declaration on line 215 of "Utilities/cmcurl/curl/multi.h".
  "Utilities/cmcurl/strerror.c", line 254.1: 1506-050 (I) Return type "unsigned char*" in
redeclaration is not compatible with the previous return type "const unsigned char*".
  "Utilities/cmcurl/strerror.c", line 283.1: 1506-343 (S) Redeclaration of curl_share_strerror
differs from previous declaration on line 1329 of "Utilities/cmcurl/curl/curl.h".
  "Utilities/cmcurl/strerror.c", line 283.1: 1506-050 (I) Return type "unsigned char*" in
redeclaration is not compatible with the previous return type "const unsigned char*".

To force it to compile, I removed the define of "const" to be empty
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan W. Irwin | 2 Mar 2007 03:58
Picon
Picon

Request for better documentation of TRY_COMPILE

To get the experimental Ada language support to work, I needed access to the
source file name at link time.  As a workaround I used Bill's suggestion of
using the <TARGET> name.  That means ADD_EXECUTABLE now works with Ada (with
properly chosen lower-case target names which agrees with the root name of
the source code file which describes the main programme of the Ada executable.
However, that workaround interferes with the second form of TRY_COMPILE
since that uses a fixed target name of cmTryCompileExec.

This limitation got me curious about the first form of
TRY_COMPILE which is documented (2.4.6) as follows:

***********
Try compiling some code.

          TRY_COMPILE(RESULT_VAR bindir srcdir
                      projectName <targetname> <CMAKE_FLAGS <Flags>>
                      <OUTPUT_VARIABLE var>)

        Try compiling a program.  Return the success or failure in RESULT_VAR.
        If <target name> is specified then build just that target otherwise
        the all or ALL_BUILD target is built.
***********

I think that documentation needs to be expanded by roughly a factor of three
to make it consistent with the size of the documentation of the second form
of try_compile which is well documented from my perspective.  I certainly
did not "get" the above terse documentation when I first read it.  Now that
I have read it over a few times, I think it must mean you should set up a
complete test project case in srcdir with source file(s), CMakeList.txt
file(s), possible sub-directories (if you need them), etc., and this form of
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brandon J. Van Every | 2 Mar 2007 04:18
Picon

Re: Request for better documentation of TRY_COMPILE

Alan W. Irwin wrote:
>
> I think that documentation needs to be expanded by roughly a factor of 
> three
> to make it consistent with the size of the documentation of the second 
> form
> of try_compile which is well documented from my perspective.  I certainly
> did not "get" the above terse documentation when I first read it.

I didn't either.  Once upon a time it caused me to completely miss the 
purpose of TRY_COMPILE and instead try to use EXECUTE_PROCESS.  
Nowadays, when I run into under-documentation, I file it as a "Content" 
bug in the bug tracker.  I've had 3 of those pending for awhile now.  
That and 2 documentation related feature requests.

>
> Due to the current terse documentation of the first form of try_compile I
> missed the implications of its infinite flexibility so instead I replaced
> the usual TRY_COMPILE test of a compiler that is part of all language
> support with an EXECUTE_PROCESS test of gnatmake.

Fools think alike!  Oh no, heavens, that's "genius minds run the same 
channel."  :-)  EXECUTE_PROCESS is an incorrect solution because it 
compiles in CMake's shell environment, not your compiler's build 
environment.  If those items are one and the same, you are merely lucky.

Cheers,
Brandon Van Every
Permalink | Reply | 0 comments |
headers
kitts | 2 Mar 2007 05:18
Picon

Re: crosscompiling problems on XP

On Thursday 01 Mar 2007 IST, Kishore, Jonnalagadda (IE10) wrote:
> I have recently tried porting a project to CMake but I am facing a few
> issues when cross-compiling
>
> The project can be compiled with a varying set of compilers (already
> works with our custom makefiles) and currently the only option seems to
> be passing this information along with the cmake command. This fails with
> different errors when executed from within the cygwin shell or the
> windows command prompt.
>
> I am doing a simple test with just two files.
>
> main.c:
> 	main()
> 	{
> 	}
>
> CMakeLists.txt:
> 	PROJECT(test)
> 	ADD_EXECUTABLE(test main.c)
>
> In the cygwin shell I get;
> $ cmake -DCMAKE_C_COMPILER=avr-gcc -DCMAKE_CXX_COMPILER=avr-g++ -G "Unix
> Makefi les" .
> -- Check for working C compiler: avr-gcc
> -- Check for working C compiler: avr-gcc -- broken
> CMake Error: The C compiler "avr-gcc" is not able to compile a simple
> test progr am.
> It fails with the following output:
>  make: Warning: File `CMakeFiles/progress.make' has modification time
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jong-young Park | 2 Mar 2007 09:18
Picon

Can I make both(STATIC & SHARED) type libraries?

I need both lib.a & lib.so as project result.
But ADD_LIBRARY command may support Only 1 type, I think.

Not any other method?

Thanks for reading.

_______________________________________________
CMake mailing list
CMake@...
http://www.cmake.org/mailman/listinfo/cmake
Permalink | Reply | 7 comments |

Gmane