Re: [CMake] External_Project and WIndows

2011-08-07 Thread Yuri Timenkov
For non-CMake project (especially VS native ones) you could use
${CMAKE_CFG_INT_DIR} variable instead (
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#variable:CMAKE_CFG_INTDIR
)

It will be evaluated into current solution's configuration. However please
note that in this case configurations in CMake should be the same as in
nested project.

And may be I misunderstood your question, but BUILD_COMMAND in external
project should work without extra quotes (that is msbuild '/p:Configuraion'
...). I suppose /p gets converted to \p because CMake interprets this whole
string as path to binary and converts path separator to native form (which
is back-slash on windows).

On Sun, Aug 7, 2011 at 1:15 AM, Bill Hoffman wrote:

> On 8/6/2011 11:53 AM, Richard Offer wrote:
>
>>
>> Hi,
>>
>> I'm trying to build Google protocol buffers as an external project on
>> Windows and am hitting an issue with over assuming something is a path.
>>
>>
>> I need to be able to call msbuild with options. (/p:Configuration=Debug),
>> but cmake converts this to \p:Configuration=Debug before passing the
>> string to msbuild.
>>
>>  This might work:
>
> cmake --build path/to/project --config Debug
>
>
> __**_
> 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] cmake support D programming?

2011-08-07 Thread jonathan MERCIER
Le samedi 06 août 2011 à 20:00 -0700, Alan W. Irwin a écrit :
> Hi Jonathan:
> 
> I certainly agree with your implicit assumption that D language
> support is important for CMake.
> 
> On 2011-08-07 03:00+0200 jonathan MERCIER wrote:
> 
> > Since Fedora 16 will add a D2 compiler (ldc), i would like to know if
> > cmake support yet this language?
> 
> As far as I know, not directly, but there is dated CMake language support
> for D via third parties.
> 
> If you download the stable version of CMake D language support (trunk-r29.zip)
> from http://www.dsource.org/projects/cmaked, you will find files
> dated 2007-08-28 in that zip.
> 
> Werner Smekal of the PLplot project downloaded those in 2009, and we
> have updated those files a bit afterwards.  They seem to work for us
> even for CMake-2.8.5, but we are not expert enough to answer questions
> about those files. (For example, we have changed things by rote
> without much understanding of language support under CMake other than
> what you can read at cmake-2.8.5/Modules/CMakeAddNewLanguage.txt). 
> You will find our versions of those D language support files at
> 
> http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support/cmake/
> and
> http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support/cmake/Platform
> 
> Ideally, CMake developers will take over these modules at some point
> or better yet develop D language support for modern CMake by doing the
> necessary minor modifications of the modern C language support they have
> already developed.
> 
> Same comment about the Ada language support files that are at the same
> PLplot location and which also work for us under the same conditions
> (mostly by rote with very little understanding).
> 
> Alan
> __
> Alan W. Irwin
> 
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
> 
> Programming affiliations with the FreeEOS equation-of-state implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __
> 
> Linux-powered Science
> __


Thanks for your answer, i have read this file:
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake?revision=10805&view=markup

And i see a problem, line 28:
SET (CMAKE_D_FLAGS_INIT "-version=Posix ${DSTDLIB_FLAGS} -I
$ENV{D_PATH}/include -I$ENV{D_PATH}/import")

include dir and import dir is same thing and in fedora d includedir is
loctated in /usr/include/d or here path have a hardcoded suffix
"/include" & "/import"



-- 
jonathan MERCIER 

___
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 support D programming?

2011-08-07 Thread Jens Mueller
jonathan MERCIER wrote:
> Dear,
> Since Fedora 16 will add a D2 compiler (ldc), i would like to know if
> cmake support yet this language? 

You can try out http://code.google.com/p/cmaked2/.
http://code.google.com/p/cmaked2/wiki/GettingStarted should get you
started.

If I find some time I will add gdc and ldc support. It is not much work
to add these.

Jens
___
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 support D programming?

2011-08-07 Thread jonathan MERCIER
Le dimanche 07 août 2011 à 10:27 +0200, Jens Mueller a écrit :
> jonathan MERCIER wrote:
> > Dear,
> > Since Fedora 16 will add a D2 compiler (ldc), i would like to know if
> > cmake support yet this language? 
> 
> You can try out http://code.google.com/p/cmaked2/.
> http://code.google.com/p/cmaked2/wiki/GettingStarted should get you
> started.
> 
> If I find some time I will add gdc and ldc support. It is not much work
> to add these.
> 
> Jens
> ___
> 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

is a great works :)
So, i would to know if cmaked2 will go to cmake ?
if not i culd package it for fedora

thanks

___
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] Assembly language support using gcc or gas

2011-08-07 Thread Glenn Coombs
Hi Alex,

I've tested your zip file example and it works as expected: the -I options
are present but not the -D options.  After some more testing of what is
different in my setup I think I have isolated the cause.  If I change this
one line in your example from this:

add_definitions(-DFOO)

to this:

add_definitions("-DFOO -DBAR")

then I get the same behaviour I was seeing before: the -DFOO -DBAR options
are passed through to the assembler command line.  I see from the
documentation that I should really be using add_definitions(-DFOO -DBAR)
without the double quotes but they were harmless before.  Should I file this
as a bug - or will it just be marked as "not a bug", i.e. don't use double
quotes like that with add_definitions ?

--
Glenn


2011/8/3 Alexander Neundorf 

> Hi,
>
> On Wednesday 03 August 2011, Glenn Coombs wrote:
> > I tried changing from ASM to ASM-ATT and that fails like this:
> >
> > /usr/bin/as  -I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src
> > -I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/kernel
> > -DNOMINMAX -DUSE_SIM_NAMESPACE -o
> > CMakeFiles/systemc.dir/src/sysc/qt/md/i386.s.o
> >
> /user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/qt/md/i386.
> > s /usr/bin/as: unrecognized option `-NOMINMAX'
> >
> > I really don't think the -I and -D options should be passed through for
> > assembler files.  They only make sense for C/C++ files.  There should be
> a
> > separate variable like CMAKE_ASM_FLAGS that is used instead of
> > CMAKE_C_FLAGS or CMAKE_CXX_FLAGS.  And maybe there needs to be a change
> to
> > the
> > add_definitions() command to allow an optional LANG argument ?  Do
> > assembers even support preprocessor definitions ?
> >
> > I was able to get it to work for both 2.8.4 and 2.8.5 with the following
> > code:
> >
> > if(UNIX)
> > list(APPEND sources "src/sysc/qt/qt.c")
> >
> > # see if we are building 32-bit or 64-bit executables
> > file(WRITE ${CMAKE_BINARY_DIR}/check_32or64bit.cpp "int main(int
> argc,
> > char *argv[]) { return 8 * sizeof(char *); }\n")
> >
> > try_run(
> > run_result
> > compile_result
> > ${CMAKE_BINARY_DIR}
> > ${CMAKE_BINARY_DIR}/check_32or64bit.cpp
> > )
> >
> > if (${run_result} EQUAL 32)
> > list(APPEND sources "src/sysc/qt/md/i386.s")
> > if(APPLE)
> > set(ASM_SYS_FLAGS "-arch i386")
> > else()
> > set(ASM_SYS_FLAGS "-32")
> > endif()
> > else()
> > list(APPEND sources "src/sysc/qt/md/iX86_64.s")
> > if(APPLE)
> > set(ASM_SYS_FLAGS "-arch x86_64")
> > else()
> > set(ASM_SYS_FLAGS "-64")
> > endif()
> > endif()
> >
> > enable_language(ASM-ATT)
> >
> > set(CMAKE_ASM-ATT_COMPILE_OBJECT "
> > ${ASM_SYS_FLAGS} -o  ")
> > endif()
> >
> > I'm not sure if this is the recommended way to do this though.  I thought
> > the documentation said to override CMAKE_ASM-ATT_COMPILE_OBJECT before
> the
> > enable_language() command.
>
> You should not have to override it.
> To set flags, there are for every enabled language CMAKE__FLAGS
> in
> the cmake cache, i.e. CMAKE_ASM-ATT_FLAGS in this case.
>
> I tried to reproduce the problem with the attached tiny project, and I
> don't
> get the problem you describe. This is the output:
>
> as-test/b$ /opt/cmake-HEAD/bin/cmake ..
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Check for working C compiler: /usr/bin/gcc
> -- Check for working C compiler: /usr/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- The ASM-ATT compiler identification is GNU
> -- Found assembler: /usr/bin/as
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /home/alex/src/CMake/build dir/CMake-
> git/Tests/Assembler/as-test/b
> as-test/b$ make VERBOSE=1
> ...
> Scanning dependencies of target hello
> make[2]: Leaving directory `/home/alex/src/CMake/build dir/CMake-
> git/Tests/Assembler/as-test/b'
> make -f CMakeFiles/hello.dir/build.make CMakeFiles/hello.dir/build
> make[2]: Entering directory `/home/alex/src/CMake/build dir/CMake-
> git/Tests/Assembler/as-test/b'
> /opt/cmake-HEAD/bin/cmake -E cmake_progress_report
> "/home/alex/src/CMake/build
> dir/CMake-git/Tests/Assembler/as-test/b/CMakeFiles" 1
>
> [ 50%] Building C object CMakeFiles/hello.dir/main.c.o
> /usr/bin/gcc  -DFOO -DBLUB=blub -DBAR=bar -I/opt/include-o
> CMakeFiles/hello.dir/main.c.o   -c "/home/alex/src/CMake/build dir/CMake-
> git/Tests/Assembler/as-test/main.c"
> /opt/cmake-HEAD/bin/cmake -E cmake_progress_report
> "/home/alex/src/CMake/build
> dir/CMake-git/Tests/Assembler/as-test/b/CMakeFiles" 2
>
> [100%] Building ASM-ATT obje

Re: [CMake] cmake support D programming?

2011-08-07 Thread Alan W. Irwin

On 2011-08-07 09:21+0200 jonathan MERCIER wrote:


Le samedi 06 août 2011 à 20:00 -0700, Alan W. Irwin a écrit :



Thanks for your answer, i have read this file:
http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/cmake/modules/language_support/cmake/Platform/Linux-dmd.cmake?revision=10805&view=markup

And i see a problem, line 28:
SET (CMAKE_D_FLAGS_INIT "-version=Posix ${DSTDLIB_FLAGS} -I
$ENV{D_PATH}/include -I$ENV{D_PATH}/import")

include dir and import dir is same thing and in fedora d includedir is
loctated in /usr/include/d or here path have a hardcoded suffix
"/include" & "/import"


Hi Jonathan:

On my Debian Squeeze system, it is even worse.  The includedir is versioned so 
that
it is /usr/include/d/4.3/.  But it makes no actual difference; the
CMake D language support with PLplot still works fine on that system.

Here is why.  I looked further for the use of D_PATH, and I found the
following in CMakeTestDCompiler.cmake

  MESSAGE(STATUS "Check for working D compiler: ${CMAKE_D_COMPILER} --
broken")
  message(STATUS "To force a specific D compiler set the DC
environment variable")
  message(STATUS "ie - export DC=\"/opt/dmd/bin/dmd\"")
  message(STATUS "If the D path is not set please use the D_PATH
variable")
  message(STATUS "ie - export D_PATH=\"/opt/dmd\"")

So it appears D_PATH is an emergency backup measure that is used if
all else fails.  Under these emergency conditions, the authors of this
module had to make some assumption about the layout of the special
version of the D compiler package.  They obviously made the simplest
assumption (the D include files would be stored in
$ENV{D_PATH}/include and/or $ENV{D_PATH}/import).  That assumption
might work in an emergency (presumably they had access to some D
compiler package with that layout) or they may have just blindly
copied it from somewhere else.  In any case, that assumption does
no harm at all for the usual case where the D_PATH environment
variable is not set since all it does is set some additional -I flags
that point to /include and /import directories that don't exist and
which are therefore effectively ignored.

I should also point out that one of the PLplot users has taken on
the responsibilty of packaging PLplot for Fedora, and he has not
reported any difficulty with D.  Thus, I suggest if you give these
language support modules a try on your own Fedora system, they will
probably work for you as well.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__
___
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] Checking for compatible compiler flags

2011-08-07 Thread Hans Johnson
Hello,

I'm trying to use the cmake feature for testing if compiler flags are valid,
but I am running into trouble with these two complier flags.  I can not
figure out how to proper escape the "+" or the "%" that I believe are
causing the failures.

cat CMakeLists.txt 

project(TestCompilerFlagTest)

include(CheckCCompilerFlag)
include(CheckCXXCompilerFlag)

set(flag -Wno-c++0x-static-nonintegral-init)
check_cxx_compiler_flag(${flag} CXX_HAS_WARNING${flag})
set(flag -features=no%anachronisms )
check_cxx_compiler_flag(${flag} CXX_HAS_WARNING${flag})


I'd appreciate any help in resolving this.

A more robust version of  /opt/cmake-2.8.4-Darwin-universal/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/CheckCXXCompilerFlag.cmake
 for use in ITK (and Slicer/SimpleITK/BRAINS) would also be acceptable.

Thanks in advance.

Hans



___
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] Checking for compatible compiler flags

2011-08-07 Thread Michael Hertling
On 08/07/2011 09:33 PM, Hans Johnson wrote:
> Hello,
> 
> I'm trying to use the cmake feature for testing if compiler flags are valid,
> but I am running into trouble with these two complier flags.  I can not
> figure out how to proper escape the "+" or the "%" that I believe are
> causing the failures.
> 
> cat CMakeLists.txt 
> 
> project(TestCompilerFlagTest)
> 
> include(CheckCCompilerFlag)
> include(CheckCXXCompilerFlag)
> 
> set(flag -Wno-c++0x-static-nonintegral-init)
> check_cxx_compiler_flag(${flag} CXX_HAS_WARNING${flag})
> set(flag -features=no%anachronisms )
> check_cxx_compiler_flag(${flag} CXX_HAS_WARNING${flag})
> 
> 
> I'd appreciate any help in resolving this.
> 
> A more robust version of  /opt/cmake-2.8.4-Darwin-universal/CMake
> 2.8-4.app/Contents/share/cmake-2.8/Modules/CheckCXXCompilerFlag.cmake
>  for use in ITK (and Slicer/SimpleITK/BRAINS) would also be acceptable.
> 
> Thanks in advance.
> 
> Hans

The result variable's name, i.e. CHECK_CXX_COMPILER_FLAG()'s second
argument, undergoes a regex evaluation in CHECK_CXX_SOURCE_COMPILES(),
so it mustn't contain regex-sensitive characters like "+". The "=" and
"%" in the other test seem to pass CHECK_CXX_COMPILER_FLAG(), but bail
out on another occasion. In general, IMO, using any special characters
except for "_" in identifiers means asking for trouble. Thus, restrict
yourself to "[A-Za-z][A-Za-z0-9_]*" - or "[A-Za-z_][A-Za-z0-9_]*" with
regard to internal variables - and your issue will probably go away.

Regards,

Michael
___
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