date:20120111

Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
 On 1/11/2012 12:04 PM, Rolf Eike Beer wrote:
  That was me. I pushed a topic to stage yesterday for review that
  improved
  FindBZip2.cmake to detect the debug library on Windows and handle both
  optimized and debug variants. CMake preloads the BZIP2_LIBRARIES
  variable with cmbzip2, which currently is ignored in that new thing.
 
 The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_*
 with whatever is needed to convince find_package(BZIP2) to use the
 CMake-built cmbzip2 library.  If you're changing the Find module for
 it then what needs to be pre-loaded may depend on which version of
 CMake is used to configure the build of CMake.  It's a bit tricky.

I pushed an updated version to topic improve-findbzip2, hopefully that would 
do it. Does this look sane? Should I merge it into next or revert the last 
patch on next?

Eike

signature.asc
Description: This is a digitally signed message part.
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] FindBZip2 (was: Dashboard issues with ExternalProject)

2012-01-11 Thread Brad King


On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:

Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:

The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_*
with whatever is needed to convince find_package(BZIP2) to use the
CMake-built cmbzip2 library.  If you're changing the Find module for
it then what needs to be pre-loaded may depend on which version of
CMake is used to configure the build of CMake.  It's a bit tricky.


I pushed an updated version to topic improve-findbzip2, hopefully that would
do it. Does this look sane?


Since you're changing the way that module looks for libraries you should
also fix up some historical wrongness in it.  The Module/readme.txt file
explains that BZIP2_LIBRARIES should not be a cache variable.  Instead
it should be a normal variable that collects the results from other
single-library searches.  Ideally the module (with config support) should
offer these cache entries for users to set:

 BZIP2_LIBRARY_RELEASE
 BZIP2_LIBRARY_DEBUG

and the output should all be in a single

 set(BZIP2_LIBRARIES optimized ${BZIP2_LIBRARY_RELEASE}
 debug ${BZIP2_LIBRARY_DEBUG})

cmake variable (not cached) whose content is adjusted for various
combinations of availability of each piece.  For compatibility you need
to honor BZIP2_LIBRARIES if it is set before the module is loaded, but you
do not need to cache it.

 Should I merge it into next or revert the last patch on next?

Which is the last patch?

-Brad
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] FindBZip2 (was: Dashboard issues with ExternalProject)

Am Mittwoch, 11. Januar 2012, 15:32:47 schrieb Brad King:
 On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:
  Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
  The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_*
  with whatever is needed to convince find_package(BZIP2) to use the
  CMake-built cmbzip2 library.  If you're changing the Find module for
  it then what needs to be pre-loaded may depend on which version of
  CMake is used to configure the build of CMake.  It's a bit tricky.
  
  I pushed an updated version to topic improve-findbzip2, hopefully that
  would do it. Does this look sane?
 
 Since you're changing the way that module looks for libraries you should
 also fix up some historical wrongness in it.  The Module/readme.txt file
 explains that BZIP2_LIBRARIES should not be a cache variable.  Instead
 it should be a normal variable that collects the results from other
 single-library searches.  Ideally the module (with config support) should
 offer these cache entries for users to set:
 
   BZIP2_LIBRARY_RELEASE
   BZIP2_LIBRARY_DEBUG
 
 and the output should all be in a single
 
   set(BZIP2_LIBRARIES optimized ${BZIP2_LIBRARY_RELEASE}
   debug ${BZIP2_LIBRARY_DEBUG})

That's the way we currently have in next.

 cmake variable (not cached) whose content is adjusted for various
 combinations of availability of each piece.  For compatibility you need
 to honor BZIP2_LIBRARIES if it is set before the module is loaded, but you
 do not need to cache it.
 
   Should I merge it into next or revert the last patch on next?
 
 Which is the last patch?

96ae584

The current problem is that CMake set BZIP2_LIBRARIES which is not cached. So 
if a user is used to set BZIP2_LIBRARIES this would only work the first time 
now. Since the variable is not cached it would eventually get lost and the 
user suddenly has an unexpected build failure. Or do I get something entirely 
wrong.

Eike

signature.asc
Description: This is a digitally signed message part.
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] FindBZip2 (was: Dashboard issues with ExternalProject)

On Wednesday 11 January 2012, Rolf Eike Beer wrote:
 Am Mittwoch, 11. Januar 2012, 15:32:47 schrieb Brad King:
  On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:
   Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
   The top-level CMakeLists.txt file in CMake needs to pre-load BZIP2_*
   with whatever is needed to convince find_package(BZIP2) to use the
   CMake-built cmbzip2 library.  If you're changing the Find module for
   it then what needs to be pre-loaded may depend on which version of
   CMake is used to configure the build of CMake.  It's a bit tricky.
   
   I pushed an updated version to topic improve-findbzip2, hopefully that
   would do it. Does this look sane?
  
  Since you're changing the way that module looks for libraries you should
  also fix up some historical wrongness in it.  The Module/readme.txt file
  explains that BZIP2_LIBRARIES should not be a cache variable.  Instead
  it should be a normal variable that collects the results from other
  single-library searches.  Ideally the module (with config support) should
  
  offer these cache entries for users to set:
BZIP2_LIBRARY_RELEASE
BZIP2_LIBRARY_DEBUG
  
  and the output should all be in a single
  
set(BZIP2_LIBRARIES optimized ${BZIP2_LIBRARY_RELEASE}

debug ${BZIP2_LIBRARY_DEBUG})
 
 That's the way we currently have in next.

How about creating an imported target and use ${BZIP2_LIBRARY_RELEASE} and 
${BZIP2_LIBRARY_DEBUG} to set the respective LOCATION properties ?
Like
add_library(ImportedLibrary::Bzip2 IMPORTED )
set_target_properties(ImportedLibrary::Bzip2
  PROPERTIES IMPORTED_CONFIGS DEBUG;RELEASE
 LOCATION_DEBUG ${BZIP2_LIBRARY_DEBUG}
 LOCATION_RELEASE ${BZIP2_LIBRARY_RELEASE} )

set(BZIP2_LIBRARIES ImportedLibrary::Bzip2 )

There is a small source incompatiblity, in the case that somebody assumes   
 
that BZIP2_LIBRARIES contains a file path, but beside that, it's a good thing 
and makes stuff work better on Windows (since if another project installs an 
exported targets file, and if those targets have been linked against the 
installed bzip2-target, they will reference the target in their export file, 
which will be found by FindBZip2.cmake at cmake-time of a using project on the 
end system, instead of depending on the full fixed path to libbzip2 on the 
developer system).

FindQt4.cmake does already create imported targets for the libs it finds.

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] RFC: standard (and not so standard) install dirs

On Wednesday 11 January 2012, Brad King wrote:
...
To support the fully flexible version, the developer must calculate the
relative path from the configured CONFIG_INSTALL_DIR (where the
Config.cmake file goes) to the configured INCLUDE_INSTALL_DIR.

It's not too hard. See ITK for example:

Depends on the definition of too ;-)
I'll see whether I can come up with some macro or helper file to make it
easier.

http://itk.org/gitweb?p=ITK.git;a=blob;f=CMakeLists.txt;hb=v4.0.0#l558

do you have suggestions how to make the code needed in the
Config.cmake files easier ?

I've done this for a few projects that allow such destinations to be
changed. If one destination is a full path then it can just be used as-is.
If it is a relative path then I start by computing the installation
prefix based on the installation depth of the Config.cmake file using
get_filename_component. Then I add on the other relative destination.

Yes, that's basically what I do here too:
https://projects.kde.org/projects/kde/kdeexamples/repository/revisions/master/show/buildsystem/HowToInstallALibrary

I don't think the case that the Config.cmake install destination is
absolute and the others are relative to an installation prefix is
important. I see no real-world use case to do things that way.

Thanks for taking your time to read and respond to this :-)
Alex
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] FindBZip2 (was: Dashboard issues with ExternalProject)

Am Mittwoch 11 Januar 2012, 22:03:52 schrieb Rolf Eike Beer:
 Am Mittwoch, 11. Januar 2012, 15:32:47 schrieb Brad King:
  On 1/11/2012 1:31 PM, Rolf Eike Beer wrote:
   Am Mittwoch 11 Januar 2012, 13:24:42 schrieben Sie:
   The top-level CMakeLists.txt file in CMake needs to pre-load
   BZIP2_*
   with whatever is needed to convince find_package(BZIP2) to use the
   CMake-built cmbzip2 library.  If you're changing the Find module
   for
   it then what needs to be pre-loaded may depend on which version of
   CMake is used to configure the build of CMake.  It's a bit tricky.
   
   I pushed an updated version to topic improve-findbzip2, hopefully
   that
   would do it. Does this look sane?
  
  Since you're changing the way that module looks for libraries you should
  also fix up some historical wrongness in it.  The Module/readme.txt file
  explains that BZIP2_LIBRARIES should not be a cache variable.  Instead
  it should be a normal variable that collects the results from other
  single-library searches.  Ideally the module (with config support)
  should
  
  offer these cache entries for users to set:
BZIP2_LIBRARY_RELEASE
BZIP2_LIBRARY_DEBUG
  
  and the output should all be in a single
  
set(BZIP2_LIBRARIES optimized ${BZIP2_LIBRARY_RELEASE}

debug
${BZIP2_LIBRARY_DEB
UG})
 
 That's the way we currently have in next.
 
  cmake variable (not cached) whose content is adjusted for various
  combinations of availability of each piece.  For compatibility you need
  to honor BZIP2_LIBRARIES if it is set before the module is loaded, but
  you do not need to cache it.
  
Should I merge it into next or revert the last patch on next?
  
  Which is the last patch?
 
 96ae584
 
 The current problem is that CMake set BZIP2_LIBRARIES which is not cached.
 So if a user is used to set BZIP2_LIBRARIES this would only work the first
 time now. Since the variable is not cached it would eventually get lost and
 the user suddenly has an unexpected build failure. Or do I get something
 entirely wrong.

I decided to give this another try before reverting it. After I hopefully 
fixed up my messed up local branch I now pushed a fixed version upstream that 
hopefully will do the right thing (tm). If not I'll wipe all this tomorrow.

Eike

signature.asc
Description: This is a digitally signed message part.
--

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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [CMake] Actual effect of set_source_files_properties with COMPILE_FLAGS - solved

2012-01-11 Thread pellegrini


Hello everybody,

that's finally OK. Indeed; everything was OK. I did not pay attention 
that the flag was actually here. I was simply not looking
in the right place. Perhaps new glasses or some rest should be my first 
resolution for 2012 !!!


sorry for the inconvenience

Eric

pellegrini a écrit :

Hello everybody,

I work on a Fortran library that for historical reasons should be 
maintained with intel fortran compiler, g95 and gfortran

on Linux, Windows and MacOS platoform. Everything everywhere :o  !

My library is made of 50 files. Among those files, most of them will 
have to be compiled with a set of flags that
does not match the CMake default ones. But, for a few of them (4 
actually) there are some slight variations. For instance,
with g95, 46 files has to compiled with -std=f2003 while the 4 others 
ones should have this flag unset.


The strategy I decided to adopt is the following:
   - use of a macro to set the standard flags (see attached file 
set_compiler_flags.cmake)
   - use of set_source_files_properties(${SOURCES} PROPERTIES 
COMPILE_FLAGS -std=f2003)

 to set the -std=f2003 flag for all the files.
   - use of set_source_files_properties(file1.f90 PROPERTIES 
COMPILE_FLAGS ) to switch off the -std=f2003

 flag for the files for which that flag should not be set.

does it look reasonable to you ?

Now my problem. When cmaking my project, I get in one subdirectories 
of CMakeFiles a file flags.make that contains the compiler flags. From 
that file,  it seems that the set_source_files_properties commands 
were correctly executed (guessing that the comment for Custom flags is 
not an actual comment). But when using nmake in verbose mode, the 
custom flags do not appear in the g95 command line. The only ones 
displayed are the one set in my set_compiler_flags macro. Is that just 
a bug on the display or is there something wrong with my settings ?


thanks a lot

Eric




--

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



--
Eric Pellegrini
Calcul Scientifique
Institut Laue-Langevin
Grenoble, France

--

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] link in dashboard title to notes file

2012-01-11 Thread Tom Deblauwe


Hello,

I'm running the svn version of cdash, and I submit a notes file when 
building/testing(with bullseye) with a ctest script. I set 
CTEST_NOTES_FILES to the correct file just before the ctest_submit() 
call. So it gets submitted ok, and when clicking on a build name in the 
dashboard page, I see the details, with the build name and then the 
view notes link. However, on the cdash website, there you have a nice 
notes icon next to the build name on the main dashboard listing. How can 
I have this too?


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

[CMake] Boost_DIR

2012-01-11 Thread Daniel Dekkers

Hi, does anyone know what this Boost_DIR variable is from the
findBoost.cmake module? And why it is never found? 

Everything works well, I use BOOST_ROOT to set the path to the Boost
distribution, just curious.

Daniel

--

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] C/CXX/Fortran Compiler not found.

2012-01-11 Thread Kedar Moharana

Dear all,
  I am trying to build from a source code using CMAKE on Windows 7. I have
no prior experience in building from source code, so I need your help in
this regard.

The application requires following external dependencies with versions
mentioned or more advanced versions:

   - CMake-2.6 (build system)
   - Qt-4.4 (UI framework)
   - gcc-4.3 (C, C++ and Fortran compilers)

So I installed CMake 2.8.7 in C:\Program files\CMake 2.8 directory,
Qt-library-4.8.0 in the C:\Qt directory. For gcc-4.3, when I googled, I
found I can install MinGW and so I installed the latest version in C:\MinGW
directory.

When I am trying to build with CMAKE command, I am getting following error
message:


The C compiler identification is unknown

The CXX compiler identification is unknown

The Fortran compiler identification is unknown

Check for working C compiler: bcc32

CMake Error: your C compiler: bcc32 was not found. Please set
CMAKE_C_COMPILER to a valid compiler path or name.

CMake Error: Internal CMake error, TryCompile configure of cmake failed

Check for working C compiler: bcc32 -- broken

CMake Error at C:/Program Files/CMake
2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):

The C compiler bcc32 is not able to compile a simple test program.

 It fails with the following output:

CMake will not be able to correctly generate this project.

Call Stack (most recent call first):

CMakeLists.txt:2 (project)

 CMake Error: your C compiler: bcc32 was not found. Please set
CMAKE_C_COMPILER to a valid compiler path or name.

CMake Error: your CXX compiler: bcc32 was not found. Please set
CMAKE_CXX_COMPILER to a valid compiler path or name.

CMake Error: your Fortran compiler: CMAKE_Fortran_COMPILER-NOTFOUND was
not found. Please set CMAKE_Fortran_COMPILER to a valid compiler path or
name.

Configuring incomplete, errors occurred!

_


I am using the Windows native command prompt.

Can anyone tell me why these compilers are not detected? If I have to give
some path, then which files do I have to edit?


Thanks in advance for your suggestion.


Best wishes

-- 
**
Kedar Moharana
Research Scholar
Laboratory for Protein Biochemistry  Biomolecular Engineering (LProBE)
Ghent University,
9000 Ghent, Belgium
**
--

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] C/CXX/Fortran Compiler not found.

2012-01-11 Thread Andreas Pakulat

On 11.01.12 11:55:32, Kedar Moharana wrote:
 Dear all,
   I am trying to build from a source code using CMAKE on Windows 7. I have
 no prior experience in building from source code, so I need your help in
 this regard.
 
 The application requires following external dependencies with versions
 mentioned or more advanced versions:
 
- CMake-2.6 (build system)
- Qt-4.4 (UI framework)
- gcc-4.3 (C, C++ and Fortran compilers)
 
 So I installed CMake 2.8.7 in C:\Program files\CMake 2.8 directory,
 Qt-library-4.8.0 in the C:\Qt directory. For gcc-4.3, when I googled, I
 found I can install MinGW and so I installed the latest version in C:\MinGW
 directory.
 
 I am using the Windows native command prompt.
 
 Can anyone tell me why these compilers are not detected? If I have to give
 some path, then which files do I have to edit?

Can you execute 'gcc' in your command prompt? Add the gcc to the PATH.

Andreas

--

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] C/CXX/Fortran Compiler not found.

2012-01-11 Thread Kedar Moharana

Dear Arjen,
  Thank you very much for the reply.
Indeed, gcc command is not working on windows command prompt.

As you mentioned, I tried to set the path with path=c:\MinGW\bin;%PATH%
command.
Now gcc is working.

when I tried to build with CMAKE, it can detect the Fortran compiler; but C
and CXX is not detected yet.

Here is the content of the C:\MinGW\bin folder:

 aclocal  aclocal-1.10  aclocal-1.11  aclocal-1.4  aclocal-1.5  aclocal-1.6
aclocal-1.7  aclocal-1.8  aclocal-1.9  addr2line.exe  ar.exe  as.exe
autoconf  autoconf-2.13  autoconf-2.68  autoheader  autoheader-2.13
autoheader-2.68  autom4te  autom4te-2.68  automake  automake-1.10
automake-1.11  automake-1.4  automake-1.5  automake-1.6  automake-1.7
automake-1.8  automake-1.9  autopoint  autoreconf  autoreconf-2.13
autoreconf-2.68  autoscan  autoscan-2.13  autoscan-2.68  autoupdate
autoupdate-2.13  autoupdate-2.68  c++.exe  c++filt.exe  cc.exe  cpp.exe
dlltool.exe  dllwrap.exe  elfedit.exe  envsubst.exe  g++.exe  gcc.exe
gcov.exe  gdb-python27.exe  gdb.exe  gdbserver-python27.exe  gdbserver.exe
gettext.exe  gettext.sh  gettextize  gfortran.exe  gprof.exe  iconv.exe
ifnames  ifnames-2.13  ifnames-2.68  ld.bfd.exe  ld.exe  libexpat-1.dll
libgcc_s_dw2-1.dll  libgettextlib-0-18-1.dll  libgettextpo-0.dll
libgettextsrc-0-18-1.dll  libgfortran-3.dll  libgmp-10.dll  libgomp-1.dll
libiconv-2.dll  libintl-8.dll  libltdl-7.dll  libmpc-2.dll  libmpfr-1.dll
libobjc-3.dll  libquadmath-0.dll  libssp-0.dll  libstdc++-6.dll  libtool
libtoolize  list  mingw32-c++.exe  mingw32-cc.exe  mingw32-g++-4.6.2.exe
mingw32-g++.exe  mingw32-gcc-4.6.2.exe  mingw32-gcc.exe
mingw32-gfortran.exe  mingw32-make.exe  mingwm10.dll  msgattrib.exe
msgcat.exe  msgcmp.exe  msgcomm.exe  msgconv.exe  msgen.exe  msgexec.exe
msgfilter.exe  msgfmt.exe  msggrep.exe  msginit.exe  msgmerge.exe
msgunfmt.exe  msguniq.exe  ngettext.exe  nm.exe  objcopy.exe  objdump.exe
pthreadGC2.dll  quserex-test.exe  ranlib.exe  readelf.exe
recode-sr-latin.exe  size.exe  strings.exe  strip.exe  windmc.exe
windres.exe  xgettext.exe
Could you suggest why C and CXX compilers are not detected yet?

Best wishes,
Kedar


On Wed, Jan 11, 2012 at 12:01 PM, Arjen Markus arjen.mar...@deltares.nlwrote:

 Hello Kedar,

 can you start the compiler from a command prompt (DOS-box)?
 That is: does the command gcc work?

 If not, then you will have to add the location of the
 compiler to your path:

 path=c:\MinGW\bin;%PATH%

 This, however, should have been taken care of by the
 installation procedure.

 CMake will be able to find the compiler from a DOS-box
 where gcc works.

 Regards,

 Arjen



 On Wed, 11 Jan 2012 11:55:32 +0100
  Kedar Moharana kedar.mohar...@ugent.be wrote:

 Dear all,
  I am trying to build from a source code using CMAKE on Windows 7. I have
 no prior experience in building from source code, so I need your help in
 this regard.

 The application requires following external dependencies with versions
 mentioned or more advanced versions:

  - CMake-2.6 (build system)
  - Qt-4.4 (UI framework)
  - gcc-4.3 (C, C++ and Fortran compilers)


 So I installed CMake 2.8.7 in C:\Program files\CMake 2.8 directory,
 Qt-library-4.8.0 in the C:\Qt directory. For gcc-4.3, when I googled, I
 found I can install MinGW and so I installed the latest version in
 C:\MinGW
 directory.

 When I am trying to build with CMAKE command, I am getting following error
 message:
 __**__

 The C compiler identification is unknown

 The CXX compiler identification is unknown

 The Fortran compiler identification is unknown

 Check for working C compiler: bcc32

 CMake Error: your C compiler: bcc32 was not found. Please set
 CMAKE_C_COMPILER to a valid compiler path or name.

 CMake Error: Internal CMake error, TryCompile configure of cmake failed

 Check for working C compiler: bcc32 -- broken

 CMake Error at C:/Program Files/CMake
 2.8/share/cmake-2.8/Modules/**CMakeTestCCompiler.cmake:52 (MESSAGE):

 The C compiler bcc32 is not able to compile a simple test program.

 It fails with the following output:

   CMake will not be able to correctly generate this project.

 Call Stack (most recent call first):

 CMakeLists.txt:2 (project)

 CMake Error: your C compiler: bcc32 was not found. Please set
 CMAKE_C_COMPILER to a valid compiler path or name.

 CMake Error: your CXX compiler: bcc32 was not found. Please set
 CMAKE_CXX_COMPILER to a valid compiler path or name.

 CMake Error: your Fortran compiler: CMAKE_Fortran_COMPILER-**NOTFOUND
 was
 not found. Please set CMAKE_Fortran_COMPILER to a valid compiler path or
 name.

 Configuring incomplete, errors occurred!

 __**___


 I am using the Windows native command prompt.

 Can anyone tell me why these compilers are not detected? If I have to give
 some path, then which files do I have to edit?


 Thanks in advance for your suggestion.


 Best wishes

 --

[CMake] CPack : Embedding other installer (.msi, .exe)

2012-01-11 Thread Nicholas Yue


Hi,

I have a packaging/installation scenario where my files are 
dependent on another MSI/EXE to be executed/install


I tried googling NSIS cpack embed installer but didn't find the 
answer.


Is somewhere I can read up on this way of packaging up and 
installer on Windows ?


I am currently using a related macro (provided by CMake) to install 
the Visual Studio redistributable so I guess it is possible.


Regards

--
Nicholas Yue
Graphics - RenderMan, Houdini, Visualization, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
http://au.linkedin.com/in/nicholasyue

--

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] C/CXX/Fortran Compiler not found.

2012-01-11 Thread Arjen Markus


Hello Kedar,

can you start the compiler from a command prompt 
(DOS-box)?

That is: does the command gcc work?

If not, then you will have to add the location of the
compiler to your path:

path=c:\MinGW\bin;%PATH%

This, however, should have been taken care of by the
installation procedure.

CMake will be able to find the compiler from a DOS-box
where gcc works.

Regards,

Arjen


On Wed, 11 Jan 2012 11:55:32 +0100
 Kedar Moharana kedar.mohar...@ugent.be wrote:

Dear all,
 I am trying to build from a source code using CMAKE on 
Windows 7. I have
no prior experience in building from source code, so I 
need your help in

this regard.

The application requires following external dependencies 
with versions

mentioned or more advanced versions:

  - CMake-2.6 (build system)
  - Qt-4.4 (UI framework)
  - gcc-4.3 (C, C++ and Fortran compilers)

So I installed CMake 2.8.7 in C:\Program files\CMake 2.8 
directory,
Qt-library-4.8.0 in the C:\Qt directory. For gcc-4.3, 
when I googled, I
found I can install MinGW and so I installed the latest 
version in C:\MinGW

directory.

When I am trying to build with CMAKE command, I am 
getting following error

message:


The C compiler identification is unknown

The CXX compiler identification is unknown

The Fortran compiler identification is unknown

Check for working C compiler: bcc32

CMake Error: your C compiler: bcc32 was not found. 
Please set

CMAKE_C_COMPILER to a valid compiler path or name.

CMake Error: Internal CMake error, TryCompile configure 
of cmake failed


Check for working C compiler: bcc32 -- broken

CMake Error at C:/Program Files/CMake
2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 
(MESSAGE):


The C compiler bcc32 is not able to compile a simple 
test program.


It fails with the following output:

   CMake will not be able to correctly generate this 
project.


Call Stack (most recent call first):

CMakeLists.txt:2 (project)

CMake Error: your C compiler: bcc32 was not found. 
Please set

CMAKE_C_COMPILER to a valid compiler path or name.

CMake Error: your CXX compiler: bcc32 was not found. 
Please set

CMAKE_CXX_COMPILER to a valid compiler path or name.

CMake Error: your Fortran compiler: 
CMAKE_Fortran_COMPILER-NOTFOUND was
not found. Please set CMAKE_Fortran_COMPILER to a valid 
compiler path or

name.

Configuring incomplete, errors occurred!

_


I am using the Windows native command prompt.

Can anyone tell me why these compilers are not detected? 
If I have to give

some path, then which files do I have to edit?


Thanks in advance for your suggestion.


Best wishes

--
**
Kedar Moharana
Research Scholar
Laboratory for Protein Biochemistry  Biomolecular 
Engineering (LProBE)

Ghent University,
9000 Ghent, Belgium
**





DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

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] CPack : Embedding other installer (.msi, .exe)

2012-01-11 Thread ycollette . nospam

Hello,

With your cmake: embed the installers in your project, install them in a tmp dir



  install(PROGRAMS 
${CMAKE_CURRENT_SOURCE_DIR}/redistributable/win64/vcredist_2005_sp1_x64.exe
  DESTINATION tmp)



Now, add the following specific NSIS commands:


  list(APPEND CPACK_NSIS_EXTRA_INSTALL_COMMANDS  
   ExecWait '$INSTDIRtmpvcredist_2005_sp1_x64.exe'
   )

For a msi installer:

list(APPEND CPACK_NSIS_EXTRA_INSTALL_COMMANDS  
 ExecWait 'msiexec /i $INSTDIRtmpmpich2-1.2.1p1-win.msi'
 )


I hope this helps,

YC

- Mail original -
De: Nicholas Yue yue.nicho...@gmail.com
À: cmake@cmake.org
Envoyé: Mercredi 11 Janvier 2012 12:43:17
Objet: [CMake] CPack : Embedding other installer (*.msi, *.exe)

Hi,

 I have a packaging/installation scenario where my files are 
dependent on another MSI/EXE to be executed/install

 I tried googling NSIS cpack embed installer but didn't find the 
answer.

 Is somewhere I can read up on this way of packaging up and 
installer on Windows ?

 I am currently using a related macro (provided by CMake) to install 
the Visual Studio redistributable so I guess it is possible.

Regards

-- 
Nicholas Yue
Graphics - RenderMan, Houdini, Visualization, OpenGL, HDF5
Custom Dev - C++ porting, OSX, Linux, Windows
http://au.linkedin.com/in/nicholasyue

--

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] C/CXX/Fortran Compiler not found.

2012-01-11 Thread Arjen Markus


Hi Kedar,

if CMake can find the Fortran compiler and the command
gcc works from that same environment/DOS-box, then I
see no particular reason why CMake should not be able to
find it. Are the messages still the same (except for
the Fortran part)?

Note that you should start in a completely clean 
directory,

as CMake keeps track of previous builds and build attempts
via all kinds of files in that directory. They may 
interfere

with the proper operation.

Regards,

Arjen
On Wed, 11 Jan 2012 12:28:25 +0100
 Kedar Moharana kedar.mohar...@ugent.be wrote:

Dear Arjen,
 Thank you very much for the reply.
Indeed, gcc command is not working on windows command 
prompt.


As you mentioned, I tried to set the path with 
path=c:\MinGW\bin;%PATH%

command.
Now gcc is working.

when I tried to build with CMAKE, it can detect the 
Fortran compiler; but C

and CXX is not detected yet.





DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.




--

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] cpack -G NSIS

2012/1/11 Andrea Crotti andrea.crott...@gmail.com:

Andrea,

Could you please not drop the ML address?
I know the reply-to-sender mode of the list may be annoying but it is
the current setup
so tha tyou need to re-add ML address when answering.


 On 01/10/2012 07:18 PM, Eric Noulard wrote:

 This does not seems to fail in the same way?

 (By the way you lack a .gitignore, which for example might contain
 Bootstrap.cmk)

 Why?
 Usually when you build CMake you do it out-of-source:

 mkdir bstrap
 cd btstrap
 /path/to/CMake/bootstrap

 if you do build in-source you can clean-up using
 git clean

 If compiling something from git generates files which are not useful
 to see they are normally simple added to .gitignore.
 Of course you can run git clean, but almost every project has its .gitignore
 and it's really not an invasive addition.

No problem I get that.
The things is I doubt that any CMake developer would be building in source
so I bet no one did face the need.

[...]

 Well then I'm not cross-compiling, and the project is really stupid,

Then I do not understand how you can
 I'm on linux and the *exe are supposed to work only on Windows,
 run cpack on Linux (archlinux 64 bit)

and not cross-compiling?

Do you produce Windows executable or Linux executable?
Which compiler are you using?

 just a test to try out a few things:

 cmake_minimum_required (VERSION 2.6)

 # we can pass the language used in the project too
 project (Hello)
 add_executable (hello hello.cpp)
 add_test (ShouldPass passing)
 add_executable (passing passing.c)

 # setting the version number with a major and minor
 set (Tutorial_VERSION_MAJOR 1)
 set (Tutorial_VERSION_MINOR 0)

 # now a new target is generated in the Makefile, package and
 source_package
 include(CPack)
 # we add a test which is supposed to pass
 include(CTest)

Would you be able to send me a zip / tgz / ...
that contains all the sources needed to compile the project,
that way I can try myself on the actual files.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.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 coloring gcc output on errror

2012-01-11 Thread Michael Hertling

On 01/10/2012 07:17 PM, vivek goel wrote:
 Is there a way to color warning/error of gcc with cmake ?

AFAIK, no, but you might remember the power of *nix, feed the output
of make VERBOSE=1 21 into sed/awk/perl/your-favorite-here and
use ANSI Control Sequence Initiators:

CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P C)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){Return 0;}\n)
SET_SOURCE_FILES_PROPERTIES(main.c PROPERTIES COMPILE_FLAGS -Wall)
ADD_EXECUTABLE(main main.c)

% cmake srcdir
...
% make VERBOSE=1 21 | sed \
-e 's%^.*: error: .*$%\x1b[37;41m\x1b[m%' \
-e 's%^.*: warning: .*$%\x1b[30;43m\x1b[m%'

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

Re: [CMake] Cmake coloring gcc output on errror

2012-01-11 Thread Michael Wild

On 01/11/2012 01:44 PM, Michael Hertling wrote:
 On 01/10/2012 07:17 PM, vivek goel wrote:
 Is there a way to color warning/error of gcc with cmake ?
 
 AFAIK, no, but you might remember the power of *nix, feed the output
 of make VERBOSE=1 21 into sed/awk/perl/your-favorite-here and
 use ANSI Control Sequence Initiators:
 
 CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
 PROJECT(P C)
 FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){Return 0;}\n)
 SET_SOURCE_FILES_PROPERTIES(main.c PROPERTIES COMPILE_FLAGS -Wall)
 ADD_EXECUTABLE(main main.c)
 
 % cmake srcdir
 ...
 % make VERBOSE=1 21 | sed \
 -e 's%^.*: error: .*$%\x1b[37;41m\x1b[m%' \
 -e 's%^.*: warning: .*$%\x1b[30;43m\x1b[m%'
 
 Regards,
 
 Michael

Does colorgcc work with CMake? That would be a *lot* easier...

--

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] cpack -G NSIS

2012-01-11 Thread Andrea Crotti


On 01/11/2012 12:37 PM, Eric Noulard wrote:

2012/1/11 Andrea Crottiandrea.crott...@gmail.com:

Andrea,

Could you please not drop the ML address?
I know the reply-to-sender mode of the list may be annoying but it is
the current setup
so tha tyou need to re-add ML address when answering.



Sorry my mistake, actually I don't need to add manually, just remember 
to press

the right key in Thunderbird..

I just wanted to try the packaging with NSIS, and since it builds exe on 
Linux
it should probably cross compile, but I didn't set anything for that 
myself so I

it might just try to compile for Linux and package in an NSIS package.

Attached the tar.gz with all the files, hopefully



hello.tar.gz
Description: GNU Zip compressed 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] cpack -G NSIS

2012/1/11 Andrea Crotti andrea.crott...@gmail.com:
 On 01/11/2012 12:37 PM, Eric Noulard wrote:


 I just wanted to try the packaging with NSIS, and since it builds exe on
 Linux
 it should probably cross compile,
 but I didn't set anything for that myselfso I
 it might just try to compile for Linux and package in an NSIS package.

Yes that the case CMake wouldn't cross-compile by itself in your use case
you did build a NSIS windows installer that contains Linux binaries.

This wouldn't be of any practical use but that's not the issue.


Ok then.
I cannot reproduce the crash with my current CMake version (git master)
however I do get an error:

$ cpack -G NSIS
CPack: Create package using NSIS
CPack: Install projects
CPack: - Run preinstall target for: Hello
CPack: - Install project: Hello
CPack: Create package
CPack Error: Problem running NSIS command: /usr/bin/makensis
/home/erk/CMake/Contrib/CPackNSIS-crash/build/_CPack_Packages/Linux/NSIS/project.nsi
Please check 
/home/erk/CMake/Contrib/CPackNSIS-crash/build/_CPack_Packages/Linux/NSIS/NSISOutput.log
for errors
CPack Error: Problem compressing the directory
CPack Error: Error when generating package: Hello

Which is due to the fact that your example did not contain any
install directive.
So NSIS refuses to build an empty package.

Add some install directive like:
install(TARGETS hello DESTINATION bin)

and I get a package:
$ cpack -G NSIS
CPack: Create package using NSIS
CPack: Install projects
CPack: - Run preinstall target for: Hello
CPack: - Install project: Hello
CPack: Create package
CPack: - package:
/home/erk/CMake/Contrib/CPackNSIS-crash/build/Hello-0.1.1-Linux.exe
generated.

CPack only package targets (executable, library) and/or files,
directories that appear
somewhere in an install command.

see
cmake --help-command install

and please read:
http://www.cmake.org/Wiki/CMake:Packaging_With_CPack
and
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.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] Copying of 3rd party DLLs in a POST-BUILD step

2012/1/11 Robert Dailey rcdai...@gmail.com:
 He probably just uses a project.vcproj.user file, and uses the
 configure_file() command on it to fill in command arguments, environment
 variables, etc etc.

 I've done this before and it works fantastically, although I have never
 tried it to force the EXE to search for my DLL files without copying them.

All of this may be worth a new Wiki entry, since those questions have popped-up
several on the list.


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.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] FindOpenAL excluding OSX frameworks

2012-01-11 Thread Andre Heider

Hi list,

I'd appreciate a little help with the following issue:
I want to use find_package(OpenAL REQUIRED) on a portable project.
But on OSX it shouldn't accept the /System framework (or any other
framework). That one lacks too much stuff, and ppl building from
source need to use OpenAL Soft from MacPorts, Fink etc (that one is a
.dylib).
FindOpenAL.cmake is able to find OpenAL Soft from various places, but
it always prefers a framework.

I tried a few approaches, but apart from them being hackish they also
did not work ;)
Any hints?

Regards,
Andre
--

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] User configuration files for Visual Studio

2012-01-11 Thread Robert Dailey

I guess I have failed to strike the interest of anyone on this?

-
Robert Dailey


On Mon, Jan 9, 2012 at 5:58 PM, Robert Dailey rcdai...@gmail.com wrote:

 there are .user files generated by newer versions of Visual Studio (since
 2005 I believe) that contain per-machine or per-workspace information. For
 all intents and purposes these are temporary files that are not checked
 into version control.

 The normal file naming convention for these are:

 project.vcproj.DOMAIN.USER.user

 Where DOMAIN is the machine/domain name, and USER is the local account
 name.

 I found out a couple of years ago that if you rename it to this:

 project.vcproj.user

 Visual Studio will treat this as defaults for the machine-specific
 version created using the naming convention I first outlined.

 The user files are useful for setting debug working directory and command
 arguments. There are some other things you can set but I have never found a
 use for them. Since I like to set these two parameters, what I've done is
 keep my template user file in version control, and use CMake's
 configure_file() to fill in the command arguments and working directory
 fields for me. This approach is a good workaround but I'd really like to
 see CMake generate these for me. Right now I have to keep 1 user file for
 each version of visual studio that can be used, and configure them
 differently based on VS IDE selection.

 Would it be suitable for CMake to incorporate this functionality? If CMake
 provided built-in support for this, we could create target properties that
 would set these fields on the target (it would set them on the generated
 user file instead of the vcproj file like normal target properties would
 do):

 set_target_properties( project PROPERTIES
DEBUG_COMMAND_ARGUMENTS -debug -reg
DEBUG_WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
 )

 I'd be happy to help implement this should David, Bill, and others find it
 to be a good idea.

 PS: I think I can do it without boost this time ;)

 -
 Robert Dailey

--

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] How not to copy a link

2012-01-11 Thread Michael Hertling

On 01/07/2012 03:52 PM, David Cole wrote:
 On Sat, Jan 7, 2012 at 9:47 AM, David Cole david.c...@kitware.com wrote:
 On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling mhertl...@online.de 
 wrote:
 On 01/06/2012 07:51 PM, Kevin Burge wrote:
 Thanks David.  These are external libraries built outside of CMake,
 without CMake, not imported via any of the import capabilities of cmake,
 and that need to be installed alongside my CMake built files.  I think
 I'm just going to do the install with the rename.  Requires me to be
 more explicit, but, it's not like it changes all that frequently.

 Isn't it sufficient to copy such SONAME symlinks as they are, along with
 the actual library files, of course? Having a symlink from the SONAME to
 the library file is a basic mean of the ABI management on platforms with
 advanced - ;-) - support of shared libraries. Besides, these symlinks
 are automatically created by ldconfig when the latter processes the
 directory.

 Anyway, w.r.t. your initial question, I'd usually suggest to use the
 GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
 to the INSTALL() command, but it seems to not work as expected:

 CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
 PROJECT(P NONE)
 SET(CMAKE_VERBOSE_MAKEFILE ON)
 EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
touch xyz.dat.0)
 EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
create_symlink xyz.dat.0 xyz.dat)
 GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
 MESSAGE(XYZ: ${XYZ})

 Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),

 ... the full path with *all* symlinks resolved (REALPATH).

 I'd expect to see

 XYZ: .../xyz.dat.0

 instead of

 XYZ: .../xyz.dat

 Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?

 Regards,

 Michael

 On 01/06/12 12:45, David Cole wrote:
 Have you considered setting the VERSION and SOVERSION target
 properties on your libraries instead of doing the symlinks yourself?
 CMake will build and install the symlinks automatically for you on
 platforms where they are supported if you set these target properties.

 http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
 http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION

 (Or was that just an example, and you need to do this with other
 symlink files that are not simply the version symlinks for a
 library...?)


 HTH,
 David
 --

 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

 It works if you use:

  GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH)

 I'm not 100% sure if the behavior is expected to be defined for
 non-full paths. Hopefully Brad sees this and chimes in. If not, I'll
 try to remember to ask him about it on Monday.


 HTH,
 David
 
 
 It appears to be resolved w.r.t. the current *source* directory when
 you do not give the full path, and since xyz.dat does not actually
 exist in the source dir, there's no way we can know that it is
 supposed to be a symlink.
 
 But get_filename_component has to work with non-existing files since
 some people need that simply to compute where files should go, or what
 other file's base names should be based on CMake variables alone...
 
 Hope that explains it better.

Yes, it does; thanks for straightening this out. Actually, it's rather
obvious that the ABSOLUTE/REALPATH clauses of GET_FILENAME_COMPONENT()
do need a reference point, but perhaps, one should document explicitly
that it's CMAKE_CURRENT_SOURCE_DIR, whereas CMAKE_CURRENT_BINARY_DIR
won't be taken into account. Elsewhere, CMake behaves differently.

 I know it's *possible* to use non-full paths in many contexts within
 CMake and still get the results you expect, but because of little
 nuggets like this, ...
 
 ... I always, always, always use full paths anyway, unconditionally. [...]

With ADD_EXECUTABLE() and ADD_LIBRARY(), too? ;-) But seriously...

 [...] I
 always recommend to everyone that they also adopt this CMake best
 practice of referring to files by their full path names whenever
 possible. It eliminates confusion, ambiguity and unintended mistaken
 results -- and is 100% absolutely worth the effort.

Definitely agreed, but there're some commands which are typically used
with relative paths, although it's not explicitly documented how they
behave in this respect. Notable examples are the already mentioned
ADD_EXECUTABLE/LIBRARY() or SET_SOURCE_FILES_PROPERTIES() - IMO, the
latter should behave in the same manner as the formers, so one can use
the same source file specifications. Perhaps, one could add a few lines
to the documentation in order to clarify for which commands/properties/
etc. a relative path does behave well, e.g. like for ADD_SUBDIRECTORY().

Regards,

Michael
--

Re: [CMake] User configuration files for Visual Studio

2012-01-11 Thread David Cole

I'm sure there are a handful of interested parties on this topic.

One concern I would have is that if we start to generate this, we
might clobber stuff that users go in and edit by hand in the Visual
Studio UI. It's a minor concern, but if I do go in and add a
PATH=1;2;3;4 to the environment, then I wouldn't want CMake to
clobber it. I could get used to editing a CMake file or a
configuration .in file for such settings though...

It's a reasonable idea.


On Wed, Jan 11, 2012 at 9:54 AM, Robert Dailey rcdai...@gmail.com wrote:
 I guess I have failed to strike the interest of anyone on this?

 -
 Robert Dailey



 On Mon, Jan 9, 2012 at 5:58 PM, Robert Dailey rcdai...@gmail.com wrote:

 there are .user files generated by newer versions of Visual Studio (since
 2005 I believe) that contain per-machine or per-workspace information. For
 all intents and purposes these are temporary files that are not checked into
 version control.

 The normal file naming convention for these are:

 project.vcproj.DOMAIN.USER.user

 Where DOMAIN is the machine/domain name, and USER is the local account
 name.

 I found out a couple of years ago that if you rename it to this:

 project.vcproj.user

 Visual Studio will treat this as defaults for the machine-specific
 version created using the naming convention I first outlined.

 The user files are useful for setting debug working directory and command
 arguments. There are some other things you can set but I have never found a
 use for them. Since I like to set these two parameters, what I've done is
 keep my template user file in version control, and use CMake's
 configure_file() to fill in the command arguments and working directory
 fields for me. This approach is a good workaround but I'd really like to see
 CMake generate these for me. Right now I have to keep 1 user file for each
 version of visual studio that can be used, and configure them differently
 based on VS IDE selection.

 Would it be suitable for CMake to incorporate this functionality? If CMake
 provided built-in support for this, we could create target properties that
 would set these fields on the target (it would set them on the generated
 user file instead of the vcproj file like normal target properties would
 do):

 set_target_properties( project PROPERTIES
    DEBUG_COMMAND_ARGUMENTS -debug -reg
    DEBUG_WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
 )

 I'd be happy to help implement this should David, Bill, and others find it
 to be a good idea.

 PS: I think I can do it without boost this time ;)

 -
 Robert Dailey



 --

 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] User configuration files for Visual Studio

2012-01-11 Thread Michael Jackson

In light of the current topic about copying 3rd Party DLLs into the build 
directory on Visual Studio one suggestion was to create this type of file. With 
that in mind I am now interested in this feature. Would make a nice addition 
and help those of us who do 32/64 dev all on the same machine where we can not 
set global paths.

Thanks
___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net  www.bluequartz.net

On Jan 11, 2012, at 9:54 AM, Robert Dailey wrote:

 I guess I have failed to strike the interest of anyone on this?
 
 -
 Robert Dailey
 
 
 On Mon, Jan 9, 2012 at 5:58 PM, Robert Dailey rcdai...@gmail.com wrote:
 there are .user files generated by newer versions of Visual Studio (since 
 2005 I believe) that contain per-machine or per-workspace information. For 
 all intents and purposes these are temporary files that are not checked into 
 version control.
 
 The normal file naming convention for these are:
 
 project.vcproj.DOMAIN.USER.user
 
 Where DOMAIN is the machine/domain name, and USER is the local account name.
 
 I found out a couple of years ago that if you rename it to this:
 
 project.vcproj.user
 
 Visual Studio will treat this as defaults for the machine-specific version 
 created using the naming convention I first outlined.
 
 The user files are useful for setting debug working directory and command 
 arguments. There are some other things you can set but I have never found a 
 use for them. Since I like to set these two parameters, what I've done is 
 keep my template user file in version control, and use CMake's 
 configure_file() to fill in the command arguments and working directory 
 fields for me. This approach is a good workaround but I'd really like to see 
 CMake generate these for me. Right now I have to keep 1 user file for each 
 version of visual studio that can be used, and configure them differently 
 based on VS IDE selection.
 
 Would it be suitable for CMake to incorporate this functionality? If CMake 
 provided built-in support for this, we could create target properties that 
 would set these fields on the target (it would set them on the generated user 
 file instead of the vcproj file like normal target properties would do):
 
 set_target_properties( project PROPERTIES
DEBUG_COMMAND_ARGUMENTS -debug -reg
DEBUG_WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
 )
 
 I'd be happy to help implement this should David, Bill, and others find it to 
 be a good idea.
 
 PS: I think I can do it without boost this time ;)
 
 -
 Robert Dailey
 
 --
 
 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] How not to copy a link

2012-01-11 Thread David Cole

On Wed, Jan 11, 2012 at 10:10 AM, Michael Hertling mhertl...@online.de wrote:
 On 01/07/2012 03:52 PM, David Cole wrote:
 On Sat, Jan 7, 2012 at 9:47 AM, David Cole david.c...@kitware.com wrote:
 On Fri, Jan 6, 2012 at 10:54 PM, Michael Hertling mhertl...@online.de 
 wrote:
 On 01/06/2012 07:51 PM, Kevin Burge wrote:
 Thanks David.  These are external libraries built outside of CMake,
 without CMake, not imported via any of the import capabilities of cmake,
 and that need to be installed alongside my CMake built files.  I think
 I'm just going to do the install with the rename.  Requires me to be
 more explicit, but, it's not like it changes all that frequently.

 Isn't it sufficient to copy such SONAME symlinks as they are, along with
 the actual library files, of course? Having a symlink from the SONAME to
 the library file is a basic mean of the ABI management on platforms with
 advanced - ;-) - support of shared libraries. Besides, these symlinks
 are automatically created by ldconfig when the latter processes the
 directory.

 Anyway, w.r.t. your initial question, I'd usually suggest to use the
 GET_FILENAME_COMPONENT(... REALPATH) command on the symlink prior
 to the INSTALL() command, but it seems to not work as expected:

 CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
 PROJECT(P NONE)
 SET(CMAKE_VERBOSE_MAKEFILE ON)
 EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
    touch xyz.dat.0)
 EXECUTE_PROCESS(COMMAND ${CMAKE_COMMAND} -E
    create_symlink xyz.dat.0 xyz.dat)
 GET_FILENAME_COMPONENT(XYZ xyz.dat REALPATH)
 MESSAGE(XYZ: ${XYZ})

 Due to the documentation of GET_FILENAME_COMPONENT(... REALPATH),

 ... the full path with *all* symlinks resolved (REALPATH).

 I'd expect to see

 XYZ: .../xyz.dat.0

 instead of

 XYZ: .../xyz.dat

 Do I misunderstand GET_FILENAME_COMPONENT() in respect thereof?

 Regards,

 Michael

 On 01/06/12 12:45, David Cole wrote:
 Have you considered setting the VERSION and SOVERSION target
 properties on your libraries instead of doing the symlinks yourself?
 CMake will build and install the symlinks automatically for you on
 platforms where they are supported if you set these target properties.

 http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:SOVERSION
 http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:VERSION

 (Or was that just an example, and you need to do this with other
 symlink files that are not simply the version symlinks for a
 library...?)


 HTH,
 David
 --

 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

 It works if you use:

  GET_FILENAME_COMPONENT(XYZ ${CMAKE_CURRENT_BINARY_DIR}/xyz.dat REALPATH)

 I'm not 100% sure if the behavior is expected to be defined for
 non-full paths. Hopefully Brad sees this and chimes in. If not, I'll
 try to remember to ask him about it on Monday.


 HTH,
 David


 It appears to be resolved w.r.t. the current *source* directory when
 you do not give the full path, and since xyz.dat does not actually
 exist in the source dir, there's no way we can know that it is
 supposed to be a symlink.

 But get_filename_component has to work with non-existing files since
 some people need that simply to compute where files should go, or what
 other file's base names should be based on CMake variables alone...

 Hope that explains it better.

 Yes, it does; thanks for straightening this out. Actually, it's rather
 obvious that the ABSOLUTE/REALPATH clauses of GET_FILENAME_COMPONENT()
 do need a reference point, but perhaps, one should document explicitly
 that it's CMAKE_CURRENT_SOURCE_DIR, whereas CMAKE_CURRENT_BINARY_DIR
 won't be taken into account. Elsewhere, CMake behaves differently.


Is it CMAKE_CURRENT_SOURCE_DIR? Or is it the current working directory
of the cmake process, which happens to be CMAKE_CURRENT_SOURCE_DIR
when you make the call ...?

 I know it's *possible* to use non-full paths in many contexts within
 CMake and still get the results you expect, but because of little
 nuggets like this, ...

 ... I always, always, always use full paths anyway, unconditionally. [...]

 With ADD_EXECUTABLE() and ADD_LIBRARY(), too? ;-) But seriously...

Yes, even with them. Exception: when I'm editing a CMakeLists file
that pre-dates my involvement, and I'm just making an edit to blend in
with what's there and working already...

And especially with add_custom_command, add_custom_target,
execute_process calls. And file DEPENDS clauses for anything.



 [...] I
 always recommend to everyone that they also adopt this CMake best
 practice of referring to files by their full path names whenever
 possible. It eliminates confusion, ambiguity and unintended mistaken
 results -- and is 100% absolutely worth the effort.

 Definitely agreed, but there're some

Re: [CMake] User configuration files for Visual Studio

2012-01-11 Thread Robert Dailey

For VS8-VS9, this won't be a big issue since Visual Studio does not use the
.user file directly, instead it copies it and creates a DOMAIN.USER.user
file instead. For VS10, however, it does not do this, so when we edit the
.user file it will use that file directly. I think VS10 is the only version
that will be of concern to your point.

I think instead of adding this to the target properties function, we should
add a new function for this, for several reasons:

1) There are a ton of properties one can set in the USER file. These would
only add to the already-cluttered target properties list.
2) Since these are all VS specific, adding a new command will be easier to
track the MS IDE specific properties.
3) If we add them to set_target_properties, we'll need to use some strange
naming convention to make it obvious that these are not portable. For
example: VS_DEBUG_USER_COMMAND_PARAMETERS. Whereas if we have a
set_user_properties command, we can give them cleaner names like
COMMAND_PARAMETERS, ENVIRONMENT_VARIABLES, WORKING_DIRECTORY, and so forth.

Example:

set_user_properties( target_name PROPERTIES COMMAND_PARAMETERS -debug
-reg ENVIRONMENT_VARIABLES=${path};INSTALL_DIR=${installdir} )

When generating for anything that isn't the VS IDE, or doesn't have a
similar, translatable concept, this function will be a no-op.

-
Robert Dailey


On Wed, Jan 11, 2012 at 9:41 AM, David Cole david.c...@kitware.com wrote:

 I'm sure there are a handful of interested parties on this topic.

 One concern I would have is that if we start to generate this, we
 might clobber stuff that users go in and edit by hand in the Visual
 Studio UI. It's a minor concern, but if I do go in and add a
 PATH=1;2;3;4 to the environment, then I wouldn't want CMake to
 clobber it. I could get used to editing a CMake file or a
 configuration .in file for such settings though...

 It's a reasonable idea.


 On Wed, Jan 11, 2012 at 9:54 AM, Robert Dailey rcdai...@gmail.com wrote:
  I guess I have failed to strike the interest of anyone on this?
 
  -
  Robert Dailey
 
 
 
  On Mon, Jan 9, 2012 at 5:58 PM, Robert Dailey rcdai...@gmail.com
 wrote:
 
  there are .user files generated by newer versions of Visual Studio
 (since
  2005 I believe) that contain per-machine or per-workspace information.
 For
  all intents and purposes these are temporary files that are not checked
 into
  version control.
 
  The normal file naming convention for these are:
 
  project.vcproj.DOMAIN.USER.user
 
  Where DOMAIN is the machine/domain name, and USER is the local account
  name.
 
  I found out a couple of years ago that if you rename it to this:
 
  project.vcproj.user
 
  Visual Studio will treat this as defaults for the machine-specific
  version created using the naming convention I first outlined.
 
  The user files are useful for setting debug working directory and
 command
  arguments. There are some other things you can set but I have never
 found a
  use for them. Since I like to set these two parameters, what I've done
 is
  keep my template user file in version control, and use CMake's
  configure_file() to fill in the command arguments and working directory
  fields for me. This approach is a good workaround but I'd really like
 to see
  CMake generate these for me. Right now I have to keep 1 user file for
 each
  version of visual studio that can be used, and configure them
 differently
  based on VS IDE selection.
 
  Would it be suitable for CMake to incorporate this functionality? If
 CMake
  provided built-in support for this, we could create target properties
 that
  would set these fields on the target (it would set them on the generated
  user file instead of the vcproj file like normal target properties would
  do):
 
  set_target_properties( project PROPERTIES
 DEBUG_COMMAND_ARGUMENTS -debug -reg
 DEBUG_WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
  )
 
  I'd be happy to help implement this should David, Bill, and others find
 it
  to be a good idea.
 
  PS: I think I can do it without boost this time ;)
 
  -
  Robert Dailey
 
 
 
  --
 
  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] C/CXX/Fortran Compiler not found.

2012-01-11 Thread Kedar Moharana

Dear Arjen,
   Just by googling I found a solution on internet which suggested to
install VB and Intel Fortran. I tried and now cmake is detecting the C, CXX
and Fortran compiler.
Thanks for the suggestion anyway.
regards,
Kedar


On Wed, Jan 11, 2012 at 1:24 PM, Arjen Markus arjen.mar...@deltares.nlwrote:

 Hi Kedar,

 if CMake can find the Fortran compiler and the command
 gcc works from that same environment/DOS-box, then I
 see no particular reason why CMake should not be able to
 find it. Are the messages still the same (except for
 the Fortran part)?

 Note that you should start in a completely clean directory,
 as CMake keeps track of previous builds and build attempts
 via all kinds of files in that directory. They may interfere
 with the proper operation.

 Regards,

 Arjen

 On Wed, 11 Jan 2012 12:28:25 +0100
  Kedar Moharana kedar.mohar...@ugent.be wrote:

 Dear Arjen,
  Thank you very much for the reply.
 Indeed, gcc command is not working on windows command prompt.

 As you mentioned, I tried to set the path with path=c:\MinGW\bin;%PATH%
 command.
 Now gcc is working.

 when I tried to build with CMAKE, it can detect the Fortran compiler; but
 C
 and CXX is not detected yet.




 DISCLAIMER: This message is intended exclusively for the addressee(s) and
 may contain confidential and privileged information. If you are not the
 intended recipient please notify the sender immediately and destroy this
 message. Unauthorized use, disclosure or copying of this message is
 strictly prohibited.
 The foundation 'Stichting Deltares', which has its seat at Delft, The
 Netherlands, Commercial Registration Number 41146461, is not liable in any
 way whatsoever for consequences and/or damages resulting from the improper,
 incomplete and untimely dispatch, receipt and/or content of this e-mail.







-- 
**
Kedar Moharana
Research Scholar
Laboratory for Protein Biochemistry  Biomolecular Engineering (LProBE)
Ghent University,
9000 Ghent, Belgium
**
--

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] cpack: Bundle vs DragNDrop vs OSXX11 vs PackageMaker

2012-01-11 Thread Mathieu Malaterre

[Happy New Year 2012 !]

Hi all,

  I am trying to release openjpeg 1.5. To distribute binary package of
this software on MacOSX, I am starring at the cpack documentation.
  I am not a MacOSX user, so could someone please point me to the
documentation for the differences in between the
Bundle/DragNDrop/OSXX11  PackageMaker generators ?
  openjpeg simply ships command line tools, so all I would need is
something simple where the executable can find the dylib from a
relative path. Right now, I have for the DragNDrop generator:

$ otool -L 
_CPack_Packages/Darwin/DragNDrop/OPENJPEG-1.5.0-Darwin/ALL_IN_ONE/bin/j2k_dump
_CPack_Packages/Darwin/DragNDrop/OPENJPEG-1.5.0-Darwin/ALL_IN_ONE/bin/j2k_dump:
libopenjpeg.1.dylib (compatibility version 1.0.0, current version 1.5.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.9)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)

while libopenjpeg.1.dylib is in ../lib relative to j2k_dump

thanks much,
-- 
Mathieu
--

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] Bug fix requests for the next release of CMake...

On Wednesday 11 January 2012, Patrick Spendrin wrote:
 Am 02.01.2012 18:11, schrieb David Cole:
  Hi all,
  
  Replies requested. Short replies only. Read on. Just a short reply
  with bug numbers or links to the bugs is all we need here. Please move
  specific discussions into the bugs themselves or start a new thread to
  talk about it... Replies on this thread should just be a collector for
  bug numbers.
  
  Example one-line reply:
http://public.kitware.com/Bug/view.php?id=12647
  
  We are aiming for quarterly releases from now on, scheduling them
  every 3 months. That would make the next release of CMake version
  2.8.8, scheduled to have an rc1 release candidate on Wed. March 7,
  2012 -- just 9 weeks from this Wednesday.
  
  If you have a particular issue that you think should be fixed for
  inclusion in 2.8.8, please bring it up within the next two weeks.
  Ideally, each issue will be discussed as needed on the mailing list to
  come to any consensus about what should be done to fix it, and then an
  entry in the bug tracker may be used to keep it on the radar screen,
  and to track activity related to it. You can see what's on the roadmap
  for this release here:
  http://public.kitware.com/Bug/roadmap_page.php?version_id=90
  
  Patches are always welcome. Patches that include testing of any new
  features, or tests that prove a bug is really fixed on the dashboards,
  basically any patch with testing is preferred over a patch with no
  testing. Also, if you are *adding* code, then you also probably need
  to add *tests* of that code, so that the coverage percentage stays as
  is or rises.
  
  Please discuss issues here as needed, and add notes to existing issues
  in the bug tracker that you are interested in seeing fixed -- we will
  be looking at the mailing list and activity in the bug tracker to help
  prioritize the bug fixes that will occur in the near future.
 
 My personal issues are:
 http://www.cmake.org/Bug/view.php?id=10994
 and connected to it: http://www.cmake.org/Bug/view.php?id=11153
 The handling of the windows drive root is not consistent/wrong, which
 leads to both errors. I checked yesterday but the patches I added in
 10994 do lead to an endless loop in 11153. I will try to come up with a
 better patch in the coming days.

IMO these are quite important issue, since they issue causes every 
FooConfig.cmake file installed by any of the KDE libraries to contain extra 
code to work around this issue, which makes them less readable and harder to 
write (and easier to get wrong).

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] subject changed: question about which bugs you're talking about

2012-01-11 Thread David Cole

On Wed, Jan 11, 2012 at 3:08 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
 On Wednesday 11 January 2012, Patrick Spendrin wrote:
 Am 02.01.2012 18:11, schrieb David Cole:
  Hi all,
 
  Replies requested. Short replies only. Read on. Just a short reply
  with bug numbers or links to the bugs is all we need here. Please move
  specific discussions into the bugs themselves or start a new thread to
  talk about it... Replies on this thread should just be a collector for
  bug numbers.
 
  Example one-line reply:
    http://public.kitware.com/Bug/view.php?id=12647
 
  We are aiming for quarterly releases from now on, scheduling them
  every 3 months. That would make the next release of CMake version
  2.8.8, scheduled to have an rc1 release candidate on Wed. March 7,
  2012 -- just 9 weeks from this Wednesday.
 
  If you have a particular issue that you think should be fixed for
  inclusion in 2.8.8, please bring it up within the next two weeks.
  Ideally, each issue will be discussed as needed on the mailing list to
  come to any consensus about what should be done to fix it, and then an
  entry in the bug tracker may be used to keep it on the radar screen,
  and to track activity related to it. You can see what's on the roadmap
  for this release here:
  http://public.kitware.com/Bug/roadmap_page.php?version_id=90
 
  Patches are always welcome. Patches that include testing of any new
  features, or tests that prove a bug is really fixed on the dashboards,
  basically any patch with testing is preferred over a patch with no
  testing. Also, if you are *adding* code, then you also probably need
  to add *tests* of that code, so that the coverage percentage stays as
  is or rises.
 
  Please discuss issues here as needed, and add notes to existing issues
  in the bug tracker that you are interested in seeing fixed -- we will
  be looking at the mailing list and activity in the bug tracker to help
  prioritize the bug fixes that will occur in the near future.

 My personal issues are:
 http://www.cmake.org/Bug/view.php?id=10994
 and connected to it: http://www.cmake.org/Bug/view.php?id=11153
 The handling of the windows drive root is not consistent/wrong, which
 leads to both errors. I checked yesterday but the patches I added in
 10994 do lead to an endless loop in 11153. I will try to come up with a
 better patch in the coming days.

 IMO these are quite important issue, since they issue causes every
 FooConfig.cmake file installed by any of the KDE libraries to contain extra
 code to work around this issue, which makes them less readable and harder to
 write (and easier to get wrong).

 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


Are you talking about http://www.cmake.org/Bug/view.php?id=10994 and
http://www.cmake.org/Bug/view.php?id=11153 ??

How do these require extra code in your config files?

I would think putting the CMakeLists file at the root of a drive would
be quite uncommon. Why is the workaround mentioned in the bug
insufficient?
--

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] link in dashboard title to notes file

2012-01-11 Thread Tom Deblauwe


Hello,

Indeed it is the svn trunk version and this tip works! Thanks.

Can it be configured that the advanced view is the default view?

Best regards
Tom

Op 11/01/2012 13:24, David Cole schreef:

Are you using CDash from svn trunk?

If so, use the Advanced view and the notes icon should be there.


On Wed, Jan 11, 2012 at 3:22 AM, Tom Deblauwetom.debla...@traficon.com  wrote:

Hello,

I'm running the svn version of cdash, and I submit a notes file when
building/testing(with bullseye) with a ctest script. I set CTEST_NOTES_FILES
to the correct file just before the ctest_submit() call. So it gets
submitted ok, and when clicking on a build name in the dashboard page, I see
the details, with the build name and then the view notes link. However, on
the cdash website, there you have a nice notes icon next to the build name
on the main dashboard listing. How can I have this too?

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


--
*Tom Deblauwe*
*RD Engineer*

Traficon International N.V.
Vlamingstraat 19
B-8560 Wevelgem
Belgium
Tel.: +32 (0)56 37.22.00
Fax: +32 (0)56 37.21.96
URL: www.traficon.com http://www.traficon.com
--

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] subject changed: question about which bugs you're talking about

On Wednesday 11 January 2012, David Cole wrote:
 On Wed, Jan 11, 2012 at 3:08 PM, Alexander Neundorf
 
 a.neundorf-w...@gmx.net wrote:
  On Wednesday 11 January 2012, Patrick Spendrin wrote:
  Am 02.01.2012 18:11, schrieb David Cole:
   Hi all,
   
   Replies requested. Short replies only. Read on. Just a short reply
   with bug numbers or links to the bugs is all we need here. Please move
   specific discussions into the bugs themselves or start a new thread to
   talk about it... Replies on this thread should just be a collector for
   bug numbers.
   
   Example one-line reply:
 http://public.kitware.com/Bug/view.php?id=12647
   
   We are aiming for quarterly releases from now on, scheduling them
   every 3 months. That would make the next release of CMake version
   2.8.8, scheduled to have an rc1 release candidate on Wed. March 7,
   2012 -- just 9 weeks from this Wednesday.
   
   If you have a particular issue that you think should be fixed for
   inclusion in 2.8.8, please bring it up within the next two weeks.
   Ideally, each issue will be discussed as needed on the mailing list to
   come to any consensus about what should be done to fix it, and then an
   entry in the bug tracker may be used to keep it on the radar screen,
   and to track activity related to it. You can see what's on the roadmap
   for this release here:
   http://public.kitware.com/Bug/roadmap_page.php?version_id=90
   
   Patches are always welcome. Patches that include testing of any new
   features, or tests that prove a bug is really fixed on the dashboards,
   basically any patch with testing is preferred over a patch with no
   testing. Also, if you are *adding* code, then you also probably need
   to add *tests* of that code, so that the coverage percentage stays as
   is or rises.
   
   Please discuss issues here as needed, and add notes to existing issues
   in the bug tracker that you are interested in seeing fixed -- we will
   be looking at the mailing list and activity in the bug tracker to help
   prioritize the bug fixes that will occur in the near future.
  
  My personal issues are:
  http://www.cmake.org/Bug/view.php?id=10994
  and connected to it: http://www.cmake.org/Bug/view.php?id=11153
  The handling of the windows drive root is not consistent/wrong, which
  leads to both errors. I checked yesterday but the patches I added in
  10994 do lead to an endless loop in 11153. I will try to come up with a
  better patch in the coming days.
  
  IMO these are quite important issue, since they issue causes every
  FooConfig.cmake file installed by any of the KDE libraries to contain
  extra code to work around this issue, which makes them less readable and
  harder to write (and easier to get wrong).
  
  Alex
  
 Are you talking about http://www.cmake.org/Bug/view.php?id=10994 and
 http://www.cmake.org/Bug/view.php?id=11153 ??
 
 How do these require extra code in your config files?
 
 I would think putting the CMakeLists file at the root of a drive would
 be quite uncommon.

AFAIK all/most of our KDE-on-Windows developers do this using subst.

Our installed Config.cmake files (not so many yet, but there will be much 
more) have code like this:
get_filename_component(rootDir
   ${CMAKE_CURRENT_LIST_DIR}/@relInstallDir@
   ABSOLUTE) # get the chosen install prefix

and because of this bug, they need additionally this line:
+ get_filename_component(rootDir ${rootDir} REALPATH)

This will not make it easier to convince people that the Config.cmake files 
are a good thing, if each of them needs a workaround.

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] User configuration files for Visual Studio

2012-01-11 Thread James Bigler

On Wed, Jan 11, 2012 at 8:41 AM, David Cole david.c...@kitware.com wrote:

 I'm sure there are a handful of interested parties on this topic.

 One concern I would have is that if we start to generate this, we
 might clobber stuff that users go in and edit by hand in the Visual
 Studio UI. It's a minor concern, but if I do go in and add a
 PATH=1;2;3;4 to the environment, then I wouldn't want CMake to
 clobber it. I could get used to editing a CMake file or a
 configuration .in file for such settings though...

 It's a reasonable idea.


I would be vehemently against any idea that would *require* me to edit any
file to change debug parameters.  This is an integral part of how VS should
be used.  The time for an iteration cycle and annoyance of this would be
too high for most developers.

1. Edit paramfile
2. Configure with CMake
3. Wait for VS to recognize the file has changed or the slow slow CMake VS
plugin to figure out what is going on and ask me to reload the file.
4. Run my code
5. Decide I need to change another debug parameter
6. Rinse and repeat until I decide to pull my hair out

I would not be opposed for a default version of the file or the option to
overwrite the existing ones, but once it has been created please leave it
alone and let me configure it through the GUI.

James
--

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] Copying of 3rd party DLLs in a POST-BUILD step

2012-01-11 Thread Ben Medina

Yes, that's exactly it. I'll try to add something to the wiki.

On Wed, Jan 11, 2012 at 6:01 AM, Eric Noulard eric.noul...@gmail.com wrote:
 2012/1/11 Robert Dailey rcdai...@gmail.com:
 He probably just uses a project.vcproj.user file, and uses the
 configure_file() command on it to fill in command arguments, environment
 variables, etc etc.

 I've done this before and it works fantastically, although I have never
 tried it to force the EXE to search for my DLL files without copying them.

 All of this may be worth a new Wiki entry, since those questions have 
 popped-up
 several on the list.


 --
 Erk
 Membre de l'April - « promouvoir et défendre le logiciel libre » -
 http://www.april.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
--

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-commits] CMake branch, next, updated. v2.8.7-2066-g8c508d2

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  8c508d230187b6f03a38b53220717989d08f4d82 (commit)
   via  c43a18e018f15e5cbb8dcddb8726ec76a5c8ace3 (commit)
   via  53da978b3cdab4eabc358f8fee0b0ee99ae8d3cf (commit)
  from  fab6cbf37535b9e253972d075ab66684e26de555 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c508d230187b6f03a38b53220717989d08f4d82
commit 8c508d230187b6f03a38b53220717989d08f4d82
Merge: fab6cbf c43a18e
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Wed Jan 11 08:57:49 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jan 11 08:57:49 2012 -0500

Merge topic 'fixSymlinkInZIP' into next

c43a18e Fix indentation style
53da978 Do not add the content of a file if it's a symlink.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c43a18e018f15e5cbb8dcddb8726ec76a5c8ace3
commit c43a18e018f15e5cbb8dcddb8726ec76a5c8ace3
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Wed Jan 11 14:55:09 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Wed Jan 11 14:55:09 2012 +0100

Fix indentation style

diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx
index d506760..e3f2299 100644
--- a/Source/cmArchiveWrite.cxx
+++ b/Source/cmArchiveWrite.cxx
@@ -250,11 +250,11 @@ bool cmArchiveWrite::AddFile(const char* file,
   // do not copy content of symlink
   if (!(archive_entry_filetype(e)  AE_IFLNK))
 {
-  // Content.
-  if(size_t size = static_castsize_t(archive_entry_size(e)))
-{
-  return this-AddData(file, size);
-}
+// Content.
+if(size_t size = static_castsize_t(archive_entry_size(e)))
+  {
+  return this-AddData(file, size);
+  }
 }
   return true;
 }

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=53da978b3cdab4eabc358f8fee0b0ee99ae8d3cf
commit 53da978b3cdab4eabc358f8fee0b0ee99ae8d3cf
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Tue Jan 10 23:19:41 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Tue Jan 10 23:19:41 2012 +0100

Do not add the content of a file if it's a symlink.

This wasn't necessary for TAR-like (TGZ, TBZ2, etc...) archive
because for those the size was 0. Either there is an error in
upstream libarchive concerning the size or we should not rely
on size of the entry for adding content.

diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx
index eab8a59..d506760 100644
--- a/Source/cmArchiveWrite.cxx
+++ b/Source/cmArchiveWrite.cxx
@@ -247,10 +247,14 @@ bool cmArchiveWrite::AddFile(const char* file,
 return false;
 }
 
-  // Content.
-  if(size_t size = static_castsize_t(archive_entry_size(e)))
+  // do not copy content of symlink
+  if (!(archive_entry_filetype(e)  AE_IFLNK))
 {
-return this-AddData(file, size);
+  // Content.
+  if(size_t size = static_castsize_t(archive_entry_size(e)))
+{
+  return this-AddData(file, size);
+}
 }
   return true;
 }

---

Summary of changes:
 Source/cmArchiveWrite.cxx |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v2.8.7-2070-g12e18cd

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  12e18cda168d748750724947278190963142610e (commit)
   via  53fcb0bc665038d947316bbf01fff38f5fd98fb3 (commit)
  from  699094b3ceb919095860626784e1f9fc9e1397e2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=12e18cda168d748750724947278190963142610e
commit 12e18cda168d748750724947278190963142610e
Merge: 699094b 53fcb0b
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Wed Jan 11 16:41:44 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jan 11 16:41:44 2012 -0500

Merge topic 'fixSymlinkInZIP' into next

53fcb0b Fix wrong test for symlink.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=53fcb0bc665038d947316bbf01fff38f5fd98fb3
commit 53fcb0bc665038d947316bbf01fff38f5fd98fb3
Author: Eric NOULARD eric.noul...@gmail.com
AuthorDate: Wed Jan 11 22:37:13 2012 +0100
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Wed Jan 11 22:37:13 2012 +0100

Fix wrong test for symlink.

It seems like:
archive_entry_filetype(e)  AE_IFLNK
is not the appropriate test for testing whether if an entryis refering
to a symlink.
archive_entry_symlink(e)
is the good one.
With this test we can skip data for both ZIP and TAR.

diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx
index e8fc45a..dc6b749 100644
--- a/Source/cmArchiveWrite.cxx
+++ b/Source/cmArchiveWrite.cxx
@@ -247,8 +247,8 @@ bool cmArchiveWrite::AddFile(const char* file,
 return false;
 }
 
-  // do not copy content of symlink for ZIP format
-  if ((archive_format(this-Archive)!=ARCHIVE_FORMAT_ZIP) || 
(!(archive_entry_filetype(e)  AE_IFLNK)))
+  // do not copy content of symlink
+  if (!archive_entry_symlink(e))
 {
 // Content.
 if(size_t size = static_castsize_t(archive_entry_size(e)))

---

Summary of changes:
 Source/cmArchiveWrite.cxx |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v2.8.7-2072-g50f851e