headers
troy d. straszheim | 1 Jul 2008 01:04
Favicon

Re: [Boost-cmake] Problem with Boost-CMake Install Rule

Miguel A. Figueroa-Villanueva wrote:
> Hello,
> 
> The following snippet from the Boost-CMake build CMakeLists.txt file
> is not working for me. Particularly, the REGEX ".svn" is causing the
> rule to create the ${BOOST_HEADER_DIR}, but doesn't copy all the files
> and subdirectories. It doesn't report any errors, it is just excluding
> everything I suppose...
> 
> install(DIRECTORY boost
>         DESTINATION ${BOOST_HEADER_DIR}
>         COMPONENT Core
>         PATTERN "CVS" EXCLUDE
>         REGEX ".svn" EXCLUDE)
> 
> The source directory is: c:/cygdir/svncopy/boost-1.35.0/boost
> The ${BOOST_HEADER_DIR} is: c:/cygdir/syncs/opt/boost-1.35.0/include/boost-1_35
> 
> If I change the line to the following, then it works as it should.
> 
> install(DIRECTORY boost
>         DESTINATION ${BOOST_HEADER_DIR}
>         COMPONENT Core
>         PATTERN "CVS" EXCLUDE
>         REGEX "/.svn$" EXCLUDE)
> 
> Now, from reading the help message, it seems to me that the above
> should work. Hence, I think there is a bug in CMake itself, but if I'm
> missinterpreting the command instructions please let me know.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miguel A. Figueroa-Villanueva | 1 Jul 2008 05:55
Picon

Re: Problem with Boost-CMake Install Rule

On Mon, Jun 30, 2008 at 7:04 PM, troy d. straszheim wrote:
> Miguel A. Figueroa-Villanueva wrote:
>>
>> Hello,
>>
>> The following snippet from the Boost-CMake build CMakeLists.txt file
>> is not working for me. Particularly, the REGEX ".svn" is causing the
>> rule to create the ${BOOST_HEADER_DIR}, but doesn't copy all the files
>> and subdirectories. It doesn't report any errors, it is just excluding
>> everything I suppose...
>>
>> install(DIRECTORY boost
>>        DESTINATION ${BOOST_HEADER_DIR}
>>        COMPONENT Core
>>        PATTERN "CVS" EXCLUDE
>>        REGEX ".svn" EXCLUDE)
>>
>> The source directory is: c:/cygdir/svncopy/boost-1.35.0/boost
>> The ${BOOST_HEADER_DIR} is:
>> c:/cygdir/syncs/opt/boost-1.35.0/include/boost-1_35
>>
>> If I change the line to the following, then it works as it should.
>>
>> install(DIRECTORY boost
>>        DESTINATION ${BOOST_HEADER_DIR}
>>        COMPONENT Core
>>        PATTERN "CVS" EXCLUDE
>>        REGEX "/.svn$" EXCLUDE)
>>
>> Now, from reading the help message, it seems to me that the above
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clemens Arth | 1 Jul 2008 08:34
Picon
Picon

Re: Visual Studio and Windows Mobile SDKs

Hi,

I took a look at your files and I think you have done a pretty good job and that should work out well. For some
reason I had to force the compiler setting to be MSVC, because cmake did not set it automatically. 

cmake --try-compile -DCMAKE_TOOLCHAIN_FILE="C:/Program Files/CMake
2.6/share/cmake-2.6/Modules/Platform/platform_wince_cl_arm.cmake" -G"Visual Studio 9 2008"
-DCMAKE_C_COMPILER_ID="MSVC" ..

As I mentioned earlier there are "Smartphone" and "PocketPC" configurations in Windows Mobile 5/6. As a
result, I still have to keep WINCE_HOST_CMAKE_PATH under "C:/Program Files/Microsoft Visual Studio
9.0/VC/ce", but I have to set WINCE_SDK_CMAKE_PATH such that I either points to "C:\Program
Files\Windows Mobile 5.0 SDK R2\PocketPC" or to "C:\Program Files\Windows Mobile 5.0 SDK
R2\SmartPhone". These subdirectories include the include/lib subdirectories in the case of wm5/6,
which I also think might be the main difference between both configurations.

I think I was not totally mistaken when I thought Mobile 5 and CE 5 were more-or-less the same, because using
your files I get quite far now. However, the linker returns an error for mobile 5 and 6:

module machine type 'X86' conflicts with target machine type 'THUMB'

This might be due to a missing compiler/linker flag I guess. Has anyone worked around that error yet?

Regards
Clemens

-------- Original-Nachricht --------
> Datum: Mon, 30 Jun 2008 11:49:19 +0200
> Von: "Andreas Pokorny" <andreas.pokorny@...>
> An: a.neundorf-work@...
(Continue reading)

Permalink | Reply | 13 comments |
headers
Clemens Arth | 1 Jul 2008 10:04
Picon
Picon

Re: Visual Studio and Windows Mobile SDKs

Hi again,

> I took a look at your files and I think you have done a pretty good job
> and that should work out well. For some reason I had to force the compiler
> setting to be MSVC, because cmake did not set it automatically. 

I also had to force the CXX compiler setting to MSVC.

> However, the linker returns an error for mobile 5 and 6:
> 
> module machine type 'X86' conflicts with target machine type 'THUMB'

Well, the main problem seems to be the fact, that after all the configuration stuff cmake still sticks to the
usual x86 compiler for compiling the test program:

  Run Build Command:C:\PROGRA~1\MICROS~1.0\Common7\IDE\devenv.com
  CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec

  Microsoft (R) Visual Studio Version 9.0.21022.8.

  Copyright (C) Microsoft Corp.  All rights reserved.

  1>------ Build started: Project: cmTryCompileExec, Configuration: Debug
  Win32 ------

  1>Compiling...

  1>Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for
  80x86
(Continue reading)

Permalink | Reply | 12 comments |
headers
Andreas Pokorny | 1 Jul 2008 11:39
Picon

Re: Visual Studio and Windows Mobile SDKs

Hi Clemens,

2008/7/1 Clemens Arth <Clemens.Arth@...>:
> Hi again,
>
>> I took a look at your files and I think you have done a pretty good job
>> and that should work out well. For some reason I had to force the compiler
>> setting to be MSVC, because cmake did not set it automatically.
>
> I also had to force the CXX compiler setting to MSVC.
>
>> However, the linker returns an error for mobile 5 and 6:
>>
>> module machine type 'X86' conflicts with target machine type 'THUMB'
>
> Well, the main problem seems to be the fact, that after all the configuration stuff cmake still sticks to
the usual x86 compiler for compiling the test program:

Could you check that the path to cl.exe or clarm.exe set inside the
TOOLCHAIN File is correct?
I do not know how cmake behaves when it cannot find the compiler. But
accordung to the output,
it looks like the normal windows cl compiler.

kind regards
Andreas
Permalink | Reply | 11 comments |
headers
Clemens Arth | 1 Jul 2008 12:14
Picon
Picon

Fwd: Re: Visual Studio and Windows Mobile SDKs

-------- Original-Nachricht --------
Datum: Tue, 01 Jul 2008 12:09:33 +0200
Von: "Clemens Arth" <Clemens.Arth@...>
An: "Andreas Pokorny" <andreas.pokorny@...>
Betreff: Re: [CMake] Visual Studio and Windows Mobile SDKs

Hi Andreas,

I changed the configuration by hand to reflect my settings, 

SET(WINCE_HOST_CMAKE_PATH "C:/Program Files/Microsoft Visual Studio 9.0/VC/ce" CACHE PATH "Path to
Visual Studio CE Path")
SET(WINCE_SDK_CMAKE_PATH "C:/Program Files/Windows Mobile 5.0 SDK R2/PocketPC" CACHE PATH "Path to
WinCE SDK")

and it seems to be some bug anyway because it reports:

-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio 9.0/VC/ce/bin/x86_arm/cl.exe
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio
9.0/VC/ce/bin/x86_arm/cl.exe -- works

However, I think that there is still something missing, because there would be a need for creating a new
"Platform" item within a vcproj file which does not happen currently. After finishing the cmake
configuration setup, there is no way to access special compiler settings in VS which are necessary, thus I
argue that there goes something wrong during configuration. For example, this is taken from a resulting
sln file:
	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug|Win32 = Debug|Win32
		Release|Win32 = Release|Win32
		MinSizeRel|Win32 = MinSizeRel|Win32
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clemens Arth | 1 Jul 2008 15:48
Picon
Picon

Re: Visual Studio and Windows Mobile SDKs

Hi again,

ok, now I had a look at the cmake source code. My question is: "Has anyone really got a cross-compile setup
running under Windows with VS?" There are some points which I've tried and I want to share my outcome with you:

First, I took a look at cmGlobalVisualStudio8Generator.cxx and at
cmLocalVisualStudio7Generator.cxx. In both files, there is "Win32" hardcoded as platform name, but
for some reason, there is also a SetPlatformName(...) function, which (in my opinion) is intended to be
used for setting up another platform name - however, my tests have shown that this function is never called
in my setup, even if I use some cross-compiler toolchain file. So I simply replaced "Win32" by "Windows
Mobile 5.0 Pocket PC SDK (ARMV4I)", which is one of the correct targets in my setting, just to find out if
that works - and it does! Now the correct compiler is used for compiling the test program, which still fails
because of the already known "mainCRTStartup" error.

I further changed four files, namely CMakeTestCCompiler.cmake, CMakeTestCxxCompiler.cmake,
CMakeCCompilerABI.cpp and CMakeCXXCompilerABI.cpp just to get the test program compiled (mainly
replacing or augmenting the int main(...) template by another int mainCRTStartup() function). Now it
finishes configuration without an error and creates my project files.

I started VS and tried to compile the outcoming solution. With setting up the different platform in
cmGlobalVisualStudio8Generator.cxx and at cmLocalVisualStudio7Generator.cxx, VS now really takes
the correct compiler, which is also reflected by the changes in the properties settings (being able to
select switches like the /QRarch4 one now). However, there are two annoying things: first, the project
always wants to link against winmm.lib, which I did not define anywhere and which causes the first linker
error. Even worse, if I remove it manually, finally I end up with a linker error: "fatal error LNK1112:
module machine type 'ARM' conflicts with target machine type 'X86'". Whatever I do, I could not manage to
resolve that one.

That's the latest status of todays work. Coming back to my initial question if somebody got
cross-compiling to work under VS: I think, calling SetPlatformName() during processing the
(Continue reading)

Permalink | Reply | 10 comments |
headers
Bill Hoffman | 1 Jul 2008 15:51
Favicon
Gravatar

cmake 2.6.1 RC 6

I have a release candidate for 2.6.1 ready for CMake.   There have not 
been any show stopper bugs in 2.6.0.  However, there have been quite a 
few fixes for 2.6.1.  I think the RC system is working thanks to the 
CMake community, so please try this version to make sure it does not 
have any regressions.   As always, report issues to me or the cmake 
list.  (And, no you did not miss other RC's, I just bump up the RC each 
time I do a commit to the 2.6 branch.)

Thanks.

The files can be found here:

http://www.cmake.org/files/v2.6/*RC-6*

The changes from 2.6.0 are as follows:

Changes in CMake 2.6.1 RC 6
- Fix DEFINITIONS property to be compatible with 2.4
- Fix escaping of $ for visual studio
- FindGettext.cmake  fix bug #7230: don't ignore first parameter if it's 
not ALL
Changes in CMake 2.6.1 RC 5
- Add support for component based packages in cpack.
- Fix FindBLAS.cmake if no fortran compiler is found
- Fix FindFLTK.cmake to pass new module test
- Fix FindKDE3.cmake to not add flags if kde3 is not found
- Fix FindMatlab.cmake, FindOpenSSL.cmake, FindQt3.cmake,
   FindSWIG.cmake, to only error if it is required
- Fix FindwxWidgets.cmake to work on msys
- Add a beta OSX bundle generator for CPack
(Continue reading)

Permalink | Reply | 3 comments |
headers
Leopold Palomo-Avellaneda | 1 Jul 2008 15:59

Re: cmake 2.6.1 RC 6

Bill,

I don't know if it's included, but the debian qt-kde maintainers have done a 
lot of patch (at least to the debian version) of the finqt4.cmake macro.

This patches are applied to cmake upstream?

Regards,

Leo

A Dimarts 01 Juliol 2008, Bill Hoffman va escriure:
> I have a release candidate for 2.6.1 ready for CMake.   There have not
> been any show stopper bugs in 2.6.0.  However, there have been quite a
> few fixes for 2.6.1.  I think the RC system is working thanks to the
> CMake community, so please try this version to make sure it does not
> have any regressions.   As always, report issues to me or the cmake
> list.  (And, no you did not miss other RC's, I just bump up the RC each
> time I do a commit to the 2.6 branch.)
>
> Thanks.
>
> The files can be found here:
>
> http://www.cmake.org/files/v2.6/*RC-6*
>
>
> The changes from 2.6.0 are as follows:
>
> Changes in CMake 2.6.1 RC 6
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bill Hoffman | 1 Jul 2008 16:02
Favicon
Gravatar

Re: cmake 2.6.1 RC 6

Leopold Palomo-Avellaneda wrote:
> Bill,
> 
> I don't know if it's included, but the debian qt-kde maintainers have done a 
> lot of patch (at least to the debian version) of the finqt4.cmake macro.
> 
> This patches are applied to cmake upstream?
> 

I don't think so, it is really hard to keep track of distro patches if 
bugs are not logged into the CMake bug tracker...  :)  Please create a 
bug, and we should be able to get it into RC 7.

Thanks.

-Bill
Permalink | Reply | 1 comment |

Gmane