Re: [CMake] Possible to clean files of one target library only?

[Marcel Loose]

On Wed, 2009-08-19 at 11:02 -0700, Tyler Roscoe wrote:
> On Wed, Aug 19, 2009 at 11:54:18AM -0600, Timothy M. Shead wrote:
> > If you are using CMake to generate makefiles, you can run "make clean" 
> > in a subdirectory of your build tree, and make will only remove the 
> > files for that directory - you can use this to do library-specific 
> > cleaning, provided that you've organized your sources so each library 
> > has its own directory.
> 
> I do not see this behavior. make clean gets rid of object files and
> libraries for the project where I run "make clean" and for all that
> project's dependencies. All my projects have their own source and binary
> directories.
> 
> tyler

Hmm, just a guess (I haven't tried it out).

Maybe it's working for Tim because he has a hierarchy of projects. I
have a big project that is subdivided into (sub)projects. As a result,
the build directory of a sub-project is a subdirectory of the build
directory of the top-level project. When I go to the build directory of
a given sub-project and issue 'make clean', only the files for that
sub-project are deleted, not those of its parent project.

So, maybe this only works if you've divided your (big) project into
sub-projects.

Best regards,
Marcel Loose.


___
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] Tests without CTest (was Re: Custom target bug...)

[Marcel Loose]

On Wed, 2009-08-19 at 21:20 -0700, Tim Kientzle wrote:
> David Cole wrote:
> > You're using incorrect arguments as DEPENDS. Things that follow DEPENDS 
> > should be full path file names... not cmake target names.
> 
> Okay, I think I finally figured out how to do what I need (which is,
> of course, to run custom test code without using CTest):
> 
># CMakeLists.txt
>PROJECT(foobar C)
>ADD_CUSTOM_TARGET(run_all_tests)
>ADD_SUBDIRECTORY(foo)
> 
># foo_test/CMakeLists.txt
>ADD_EXECUTABLE(foo_test foo_test.c)
>ADD_CUSTOM_TARGET(run_foo_test COMMAND foo_test)
>ADD_DEPENDENCIES(run_all_tests run_foo_test)
> 
> With this, I can easily add other subdirectories with
> their own test code and build up run_all_tests
> conditionally depending on which modules are enabled.
> 
> I recall someone else asked this list recently about
> using DejaGNU tests with CMake; I believe this approach
> should work for that as well.
> 
> Cheers,
> 
> Tim

Hi Tim,

Did you read this http://www.cmake.org/Wiki/CMakeEmulateMakeCheck Wiki
page and this http://www.mail-archive.com/cmake@cmake.org/msg19936.html
thread on the mailing list?

Best regards,
Marcel Loose.


___
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 Digest, Vol 64, Issue 50

[Marcel Loose]

Hi Steve,

Unless you're using make's -j option, there should not be any
concurrency issues. Check the command line and your MAKEFLAGS variable.

Best regards,
Marcel Loose.

On Wed, 2009-08-19 at 17:31 -0700, Steve Mathers wrote:
> Hi Michael.  that option is what I am already doing, which is why I am 
> confused.  'make' from the terminal works great, 'make' from eclipse craps 
> out.  
> 
> I tried running eclipse from the terminal, and it didnt help.
> 
> I noticed something else strange
> 
> here is the output from eclipse once I have done a make from the terminal, 
> then done a build in eclipse (essentially nothing to do, so eclipse doesnt 
> bomb)
> 
> 
>  Build of configuration Linux GCC for project mdc 
> 
> make  VERBOSE=1 -d 
> GNU Make 3.81
> Copyright (C) 2006  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> 
> This program built for i686-redhat-linux-gnu
> Reading makefiles...
> Reading makefile `Makefile'...
> Updating makefiles
>  Considering target file `Makefile'.
>   Looking for an implicit rule for `Makefile'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `Makefile,v'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `RCS/Makefile,v'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `RCS/Makefile'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `s.Makefile'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `SCCS/s.Makefile'.
>   No implicit rule found for `Makefile'.
>   Finished prerequisites of target file `Makefile'.
>  No need to remake target `Makefile'.
> Updating goal targets
> 
> etc
> 
> 
> NOW, here is the output having modfiied foo so that it needs to be rebuilt.  
> (one run)
> 
> 
> 
>  Build of configuration Linux GCC for project mdc 
> 
> make VERBOSE=1 -d 
> GNU Make 3.81
> Copyright (C) 2006  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> 
> This program built for i686-redhat-linux-gnu
> Reading makefiles...
> Reading makefile `Makefile'...
> Updating makefiles
>  Considering target file `Makefile'.
>   Looking for an implicit rule for `Makefile'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `Makefile,v'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `RCS/Makefile,v'.
> make[2]: *** [CMakeFiles/appmonitor.dir/AppMonitor/foo.cpp.o] Error 1
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `RCS/Makefile'.
> make[1]: *** [CMakeFiles/appmonitor.dir/all] Error 2
> make: *** [all] Error 2
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `s.Makefile'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `SCCS/s.Makefile'.
>   No implicit rule found for `Makefile'.
> 
> --
> and here is the output of a second run...
> 
> notice how the errors are reported in different stages...  is that because 
> there is some kind of concurrnecy thing going on with the build or what?  Is 
> it important?  I have no clue about this, but it seems to me that eclipse is 
> alomst trying to compete with the makefile if that makes sense?  I dont 
> know...
> 
>  Build of configuration Linux GCC for project mdc 
> 
> make VERBOSE=1 -d 
> GNU Make 3.81
> Copyright (C) 2006  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> make[2]: *** [CMakeFiles/appmonitor.dir/AppMonitor/foo.cpp.o] Error 1
> make[1]: *** [CMakeFiles/appmonitor.dir/all] Error 2
> make: *** [all] Error 2
> PARTICULAR PURPOSE.
> 
> This program built for i686-redhat-linux-gnu
> Reading makefiles...
> Reading makefile `Makefile'...
> Updating makefiles
>  Considering target file `Makefile'.
>   Looking for an implicit rule for `Makefile'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `Makefile,v'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `RCS/Makefile,v'.
>   Trying pattern rule with stem `Makefile'.
>   Trying implicit prerequisite `RCS/Makefile'.
>   Trying pattern rule with stem `Makefile'.
> 
> 
> - Original Message 
> 
> > Message: 4
> > Date: Wed, 19 Aug 2009 09:56:35 -0400
> > From: Michael Jackson 
> > Subject: Re: [CMake] eclipse-cmake b

Re: [CMake] cmake on the BGP

[Brad King]

John R. Cary wrote:
> I am trying to build cmake on a Blue Gene P.
> Configuration starts with
> 
> 
> login1.surveyor$ ./bootstrap
> -
> CMake 2.6-4, Copyright (c) 2007 Kitware, Inc., Insight Consortium
[snip]
> http://www.cmake.org/pipermail/cmake/2006-January/007917.html
> 
> "It should be very easy to add support to CMake.
> 
> You would have to create a Linux-xlc.cmake file that will
> go in the Platforms directory of cmake.   It would set all
> the correct flags for the compiler.  If you want, I can help
> you create one, and I will add it to cmake."
> 
> Was this ever done?  Can I help with getting it done?

I think it was done, at least partly.

Please try CMake from CVS HEAD:

  cvs -d :pserver:anon...@www.cmake.org:/cvsroot/CMake co CMake

If that doesn't work out of the box I'll be happy to help you
contribute support.

Thanks,
-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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake on the BGP

[John R. Cary]

Brad King wrote:

John R. Cary wrote:
  

I am trying to build cmake on a Blue Gene P.
Configuration starts with


login1.surveyor$ ./bootstrap
-
CMake 2.6-4, Copyright (c) 2007 Kitware, Inc., Insight Consortium


[snip]
  

http://www.cmake.org/pipermail/cmake/2006-January/007917.html

"It should be very easy to add support to CMake.

You would have to create a Linux-xlc.cmake file that will
go in the Platforms directory of cmake.   It would set all
the correct flags for the compiler.  If you want, I can help
you create one, and I will add it to cmake."

Was this ever done?  Can I help with getting it done?



I think it was done, at least partly.

Please try CMake from CVS HEAD:

  cvs -d :pserver:anon...@www.cmake.org:/cvsroot/CMake co CMake

If that doesn't work out of the box I'll be happy to help you
contribute support.
  

Great!  I now have the cvs checkout.

Error below indicates that it finds cc instead of xlc, which I can fix 
on the configure

line via

env CC=xlc_r CXX=xlC_r

but then it still fails at the same place.

Thx.John Cary

cc -I/home/cary/projects/facetspkgs-surveyor/CMake/Source   
-I/home/cary/projects/facetspkgs-surveyor/CMake/Bootstrap.cmk 
-DKWSYS_NAMESPACE=cmsys  -c 
/home/cary/projects/facetspkgs-surveyor/CMake/Source/kwsys/System.c -o 
System.o
xlC  -I/home/cary/projects/facetspkgs-surveyor/CMake/Source   
-I/home/cary/projects/facetspkgs-surveyor/CMake/Bootstrap.cmk  cmake.o 
cmakemain.o cmakewizard.o cmCommandArgumentLexer.o 
cmCommandArgumentParser.o cmCommandArgumentParserHelper.o 
cmDefinitions.o cmDepends.o cmDependsC.o cmDocumentationFormatter.o 
cmDocumentationFormatterText.o cmPolicies.o cmProperty.o cmPropertyMap.o 
cmPropertyDefinition.o cmPropertyDefinitionMap.o cmMakeDepend.o 
cmMakefile.o cmExportFileGenerator.o cmExportInstallFileGenerator.o 
cmInstallDirectoryGenerator.o cmGeneratedFileStream.o 
cmGeneratorExpression.o cmGlobalGenerator.o cmLocalGenerator.o 
cmInstallGenerator.o cmInstallExportGenerator.o 
cmInstallFilesGenerator.o cmInstallScriptGenerator.o 
cmInstallTargetGenerator.o cmScriptGenerator.o cmSourceFile.o 
cmSourceFileLocation.o cmSystemTools.o cmTestGenerator.o cmVersion.o 
cmFileTimeComparison.o cmGlobalUnixMakefileGenerator3.o 
cmLocalUnixMakefileGenerator3.o cmMakefileExecutableTargetGenerator.o 
cmMakefileLibraryTargetGenerator.o cmMakefileTargetGenerator.o 
cmMakefileUtilityTargetGenerator.o cmBootstrapCommands.o cmCommands.o 
cmTarget.o cmTest.o cmCustomCommand.o cmDocumentVariables.o 
cmCacheManager.o cmListFileCache.o cmComputeLinkDepends.o 
cmComputeLinkInformation.o cmOrderDirectories.o cmComputeTargetDepends.o 
cmComputeComponentGraph.o cmExprLexer.o cmExprParser.o 
cmExprParserHelper.o cmListFileLexer.o Directory.o Glob.o 
RegularExpression.o SystemTools.o ProcessUNIX.o String.o System.o -o cmake
loading initial cache file 
/home/cary/projects/facetspkgs-surveyor/CMake/Bootstrap.cmk/InitialCacheFlags.cmake

-- The C compiler identification is GNU
-- The CXX compiler identification is XL
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: 
/gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC
-- Check for working CXX compiler: 
/gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC 
-- broken

CMake Error at Modules/CMakeTestCXXCompiler.cmake:30 (MESSAGE):
 The C++ compiler
 
"/gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC"

 is not able to compile a simple test program.

 It fails with the following output:

  Change Dir: 
/home/cary/projects/facetspkgs-surveyor/CMake/CMakeFiles/CMakeTmp




 Run Build Command:/usr/bin/gmake "cmTryCompileExec/fast"

 gmake -f CMakeFiles/cmTryCompileExec.dir/build.make
 CMakeFiles/cmTryCompileExec.dir/build

 gmake[1]: Entering directory
 `/gpfs/home/cary/projects/facetspkgs-surveyor/CMake/CMakeFiles/CMakeTmp'

 /home/cary/projects/facetspkgs-surveyor/CMake/Bootstrap.cmk/cmake -E
 cmake_progress_report
 
/home/cary/projects/facetspkgs-surveyor/CMake/CMakeFiles/CMakeTmp/CMakeFiles

 1

 Building CXX object CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o


 
/gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC

 -o CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -c
 
/home/cary/projects/facetspkgs-surveyor/CMake/CMakeFiles/CMakeTmp/testCXXCompiler.cxx



 Linking CXX executable cmTryCompileExec

 /home/cary/projects/facetspkgs-surveyor/CMake/Bootstrap.cmk/cmake -E
 cmake_link_script CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1


 
/gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC

 -fPIC CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -o
 cmTryCompileExec -rdynamic


 
/gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg

Re: [CMake] linking with .so w/ non-standard names

[Brad King]

Bill Hoffman wrote:
> So, it must be that the library is built with no soname.   Brad will be
> back in a few days, and should have a better idea of how to fix it.

This is probably the problem.  You can confirm this by running

  readelf -d /home/kchang/sandbox/thost/thostmduserapi.so |grep SONAME

If a line like this:

  0x000e (SONAME) Library soname: [...]

does not appear then there is no soname.

> For now, you can do one of these:
> 
> 1. rename the library to have lib in front of it  libthostmduserapi.so

...or create a symlink to it with that name and give the full
path to the symlink to CMake.

> 2. Rebuild thostmduserapi.so with an soname

This is the best fix.  Shared libraries should always have the
soname field set because that is how the runtime linker is supposed
to locate the library.

I would be interested in an explanation from the authors of that
library as to why it has no 'lib' prefix or soname.

> 3. Add this to your CMakeLists.txt file:
> 
> set(CMAKE_PLATFORM_USES_PATH_WHEN_NO_SONAME FALSE)
> 
> before the target_link_library call. But, that might have some bad rpath
> information.

It will work but the resulting binary will only run on the machine
where it is built and always use thostmduserapi.so from that full
path.

4.) You can also tell CMake to use the full path by creating
an IMPORTED target for the library:

  add_library(thostmduserapi SHARED IMPORTED)
  set_property(TARGET thostmduserapi PROPERTY
IMPORTED_LOCATION /home/kchang/sandbox/thost/thostmduserapi.so)
  target_link_libraries(myexe thostmduserapi)

Now CMake will use the full path, but the restrictions on running
the result will be the same as option #3 above.

-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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake on the BGP

[Brad King]

John R. Cary wrote:
> env CC=xlc_r CXX=xlC_r
[snip]
> -- The C compiler identification is GNU

Be sure to create a fresh build tree when changing compilers.
CMake cached the 'cc' (gnu) compiler it found the first time
and did not pay attention to the environment later.

> /gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC:
>  1501-216 (W) command option -dynamic is not recognized - passed to ld
>  /usr/bin/ld: unrecognized option '-dynamic'

It looks like support for the C compiler was added but not
C++, and also that this combination is not well tested.  I
can help you finish adding support.  Look in Modules/Platform
at the files

  Linux.cmake
  Linux-XL-C.cmake

The first contains default flags for Linux, which are for GCC.
The second contains compiler-specific flags for the XL C compiler
on Linux.  Copy it to the file

  Linux-XL-CXX.cmake

and change the ..._C_FLAGS variable names to ..._CXX_FLAGS.
Also, please read through Linux.cmake and check for the options
in the XL compiler documentation to see if other flags need to
be changed.


BTW, a platform/compiler combination is officially supported
only if someone is contributing nightly testing to the dashboard:

  http://www.cdash.org/CDash/index.php?project=CMake

After we get this working, do you have about an hour of
spare computing time on a machine at night?  If you can
submit testing results then we can support this platform
permanently.


Thanks,
-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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] cmake on the BGP

[John R. Cary]

Brad King wrote:


Be sure to create a fresh build tree when changing compilers.
CMake cached the 'cc' (gnu) compiler it found the first time
and did not pay attention to the environment later.

Got it.  Now 'rm -rf' on the build tree.



/gpfs/software/linux-sles10-ppc64/apps/ibmcmp-sep2008/opt/vacpp/bg/9.0/bin/xlC:
 1501-216 (W) command option -dynamic is not recognized - passed to ld
 /usr/bin/ld: unrecognized option '-dynamic'


It looks like support for the C compiler was added but not
C++, and also that this combination is not well tested.  I
can help you finish adding support.  Look in Modules/Platform
at the files

  Linux.cmake
  Linux-XL-C.cmake

The first contains default flags for Linux, which are for GCC.
The second contains compiler-specific flags for the XL C compiler
on Linux.  Copy it to the file

  Linux-XL-CXX.cmake

and change the ..._C_FLAGS variable names to ..._CXX_FLAGS.
Also, please read through Linux.cmake and check for the options
in the XL compiler documentation to see if other flags need to
be changed.


So do I understand correctly that one uses

Linux-XL-CXX.cmake

to override settings in Linux.cmake?

Here is what I have now:

login3.surveyor$ ls ../Modules/Platform/Linux-XL-C*.cmake
../Modules/Platform/Linux-XL-C.cmake  ../Modules/Platform/Linux-XL-CXX.cmake
login3.surveyor$ cat ../Modules/Platform/Linux-XL-C*.cmake
SET(CMAKE_SHARED_LIBRARY_C_FLAGS "")
SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
SET(CMAKE_SHARED_LIBRARY_C_FLAGS "-DPIC")
SET(CMAKE_SHARED_LIBRARY_CXX_FLAGS "")
SET(CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS "")
SET(CMAKE_SHARED_LIBRARY_CXX_FLAGS "-DPIC")

The bootstrap "make" dies now at

[  5%] Building C object 
Source/kwsys/CMakeFiles/cmsysTestDynload.dir/testDynload.o

Linking C shared module libcmsysTestDynload.so
/usr/lib/gcc/powerpc64-suse-linux/4.1.2/../../../../lib/crt1.o:(.rodata+0x4): 
undefined reference to `main'

make[2]: *** [Source/kwsys/libcmsysTestDynload.so] Error 1
make[1]: *** [Source/kwsys/CMakeFiles/cmsysTestDynload.dir/all] Error 2
make: *** [all] Error 2


Can I turn off shared lib usage altogether?  (Problematic on BGP).
I did not see

Suppose I get a CMake that has the above in its
share dir, and I want to use my own Linux-XL-CXX.cmake.
Can I simply put my file in my project's top CMake dir?  Do I have
to include it somehow?



BTW, a platform/compiler combination is officially supported
only if someone is contributing nightly testing to the dashboard:

  http://www.cdash.org/CDash/index.php?project=CMake

After we get this working, do you have about an hour of
spare computing time on a machine at night?  If you can
submit testing results then we can support this platform
permanently.


I think I will not be able to get permission to run nightly tests at
this supercomputer center.  My guess, however, is that VisualAge
and XL are basically the same, and I could get VisualAge on my
Linux box.

John Cary


--
Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303
c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572

___
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] pg compilers on the Cary XT4

[John R. Cary]

which is basically Linux.

Building a project with pgcc/pgCC.


All flags are empty:

CMAKE_CXX_COMPILER   
/opt/pgi/8.0.4/linux86-64/8.0-4/bin/pgCC
CMAKE_CXX_FLAGS   

CMAKE_CXX_FLAGS_DEBUG 

CMAKE_CXX_FLAGS_MINSIZEREL

CMAKE_CXX_FLAGS_RELEASE   

CMAKE_CXX_FLAGS_RELWITHDEBINFO 


Where should I add these?


Another question: The default builds seem to be DEBUG,
MINSIZEREL, RELEASE, RELWITHDEBINFO.  Suppose I wanted
to define a new kind of build, e.g., PERFORMANCE.
How can I go about doing this?

ThanksJohn Cary




--
Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303
c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572

___
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] .vfproj with cmake

[lokmane.abbas-turki]

 




> Message du 18/08/09 22:56
> De : "Bill Hoffman"
> A : "lokmane.abbas-turki"
> Copie à :
> Objet : Re: [CMake] .vfproj with cmake
>
>
> OK, can you try this.
>
>
> 1. Run cmake --debug-trycompile
>
> 2. Do not load the project into the IDE.
>
> 3. Edit the cmTryCompileExec.vfproj file created by CMake,
>
> Make this change in the file:
>
> Version="9.10" to Version="11.0"
>
> 4. Try to load in the IDE, it should not give an error at this point.
>

Yes, it does not give an error.

>
> If this works, then we are going to have to change
> cmLocalVisualStudio7Generator.cxx to output the right version of Fortran
> project files.

I don't have this file in my CMake and Visual Studio directories.

Lokman.

>
> -Bill
>
> 

 Créez votre adresse électronique prenom@laposte.net 
 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
___
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] F90 and legacy F77

[Brad King]

Arjen Markus wrote:
> I do not think this is going to work: object files created with g77
> and gfortran are not compatible as far as I know.
> 
> What constructs are they? F90/95 has one or two deleted features
> but most compilers will simply accept them, perhaps grudgingly.
[snip]
>> How can this be done with CMake?
>>
>> For example:
>> foo.f   <-- F77 file
>> bar.f90  <-- F90 file
>>
>> I want something equivalent to
>> g77 foo.f -o foo.o
>> gfotran bar.f90 foo.o -o executable.x

As Arjen asked, what is your actual use case?
What are the real compiler you're using (and versions)?
Does it work when invoking the compilers by hand?
Are there compatibility flags to the f90 compiler to tell
it to accept f77 constructs?

-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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] pg compilers on the Cary XT4

[Will Dicharry]

John R. Cary wrote:

which is basically Linux.

Building a project with pgcc/pgCC.


All flags are empty:

CMAKE_CXX_COMPILER   
/opt/pgi/8.0.4/linux86-64/8.0-4/bin/pgCC
CMAKE_CXX_FLAGS   

CMAKE_CXX_FLAGS_DEBUG 

CMAKE_CXX_FLAGS_MINSIZEREL

CMAKE_CXX_FLAGS_RELEASE   


CMAKE_CXX_FLAGS_RELWITHDEBINFO
Where should I add these?


Hi John,

I use CMake to build software on Cray XT3, 4, and 5 machines.  I started 
on an XT3 with a Catamount backend, so a cross compile was actually 
necessary and I set the above options in a toolchain file and passed the 
file into cmake with -DCMAKE_TOOLCHAIN_FILE.


For the XT4, the CNL backend no longer requires a cross compile. We had 
a discussion on the list about this last month, and for setting the 
compilers I believe the consensus was to either:


1.  Set them as environment variables.  CMake will check the value of 
the environment variables CC, CXX, and FC for the names of the C, C++, 
and Fortran compilers respectively.


2. Use cmake -C to pass an initial cache containing CMAKE_C_COMPILER, 
CMAKE_CXX_COMPILER, etc.





Another question: The default builds seem to be DEBUG,
MINSIZEREL, RELEASE, RELWITHDEBINFO.  Suppose I wanted
to define a new kind of build, e.g., PERFORMANCE.
How can I go about doing this?


When using the makefile generator, you can define a new build type by 
setting it in the CMAKE_BUILD_TYPE variable and defining language flags 
for that type, so you could do something like:


set( CMAKE_BUILD_TYPE PERFORMANCE )
set( CMAKE_C_FLAGS_PERFORMANCE "-O3" )
set( CMAKE_CXX_FLAGS_PERFORMANCE "-O3" )

take a look at http://www.cmake.org/Wiki/CMake_Useful_Variables in the 
CMAKE_BUILD_TYPE section.


Hope this helps,
Will



ThanksJohn Cary







--
Will Dicharry
Software Developer
Stellar Science Ltd Co


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] [New Module] FindHDF5.cmake

[Brad King]

Will Dicharry wrote:
> Sorry for the month of delay, but I've addressed Mike Jackson's concerns
> below and I think I'm close to having the HDF5 find module ready for
> submission.

Excellent.  I have a few comments from quickly glancing at them, but
I don't have time for thorough testing.  Overall it looks good.

> There are two modules attached to this message: The FindHDF5.cmake
> module and an AdjustLibraryVariables.cmake module, which is essentially
> a copy of what the FindQt4 module does.  It seems useful enough to
> incorporate into the CMake Modules, and I can maintain it if you need a
> maintainer.

I'd like to choose a better name for AdjustLibraryVariables.  Perhaps
"SelectLibraryConfigurations"?  Does it have all the functionality needed
to update FindQt4 to use it too (you don't need to do this but it should
be easy for the FindQt4 maintainer to do it)?

The find_path and find_library calls need some tweaking.  Please read
the documentation of these commands to distinguish the cases of PATHS
and HINTS keywords.  The PATHS should only be last-resort guesses.
The HINTS should be locations computed from the system, such as those
reported by the hdf5 compiler wrapper tools.  Also, paths like

  /usr/local/include
  /usr/include

are searched automatically and need not be listed.

> How I addressed Mike Jackson's concerns is addressed in the module
> documentation at the top of the file, please let me know if anyone has
> any other concerns.

Try placing these modules in the CMake/Modules source tree and running

  cmake --help-module FindHDF5
  cmake --help-module AdjustLibraryVariables

to make sure the documentation formats correctly.  Also, any macro in
the public interface of the module should be documented using a format
similar to the CMake command documentation.

Thanks,
-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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [New Module] FindHDF5.cmake

[Will Dicharry]

Brad King wrote:

Will Dicharry wrote:

Sorry for the month of delay, but I've addressed Mike Jackson's concerns
below and I think I'm close to having the HDF5 find module ready for
submission.


Excellent.  I have a few comments from quickly glancing at them, but
I don't have time for thorough testing.  Overall it looks good.


There are two modules attached to this message: The FindHDF5.cmake
module and an AdjustLibraryVariables.cmake module, which is essentially
a copy of what the FindQt4 module does.  It seems useful enough to
incorporate into the CMake Modules, and I can maintain it if you need a
maintainer.


I'd like to choose a better name for AdjustLibraryVariables.  Perhaps
"SelectLibraryConfigurations"?  Does it have all the functionality needed
to update FindQt4 to use it too (you don't need to do this but it should
be easy for the FindQt4 maintainer to do it)?


I agree, SelectLibraryConfigurations is better.  I'll rename it.  It 
looks like I need to set ${basename}_LIBRARIES (plural) too in order for 
the Qt4 module to use it, I'll go ahead and do that.




The find_path and find_library calls need some tweaking.  Please read
the documentation of these commands to distinguish the cases of PATHS
and HINTS keywords.  The PATHS should only be last-resort guesses.
The HINTS should be locations computed from the system, such as those
reported by the hdf5 compiler wrapper tools.  Also, paths like

  /usr/local/include
  /usr/include

are searched automatically and need not be listed.



I'll clean that up, I think the only path I'm specifying that should be 
in the PATH section is the $HOME/.local/ guess.  It seems everything 
else should be a HINT.  Thanks for the tip.



How I addressed Mike Jackson's concerns is addressed in the module
documentation at the top of the file, please let me know if anyone has
any other concerns.


Try placing these modules in the CMake/Modules source tree and running

  cmake --help-module FindHDF5
  cmake --help-module AdjustLibraryVariables

to make sure the documentation formats correctly.  Also, any macro in
the public interface of the module should be documented using a format
similar to the CMake command documentation.


What is the convention for keeping a macro out of the public interface?

Thanks for your help,
Will



Thanks,
-Brad



--
Will Dicharry
Software Developer
Stellar Science Ltd Co


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] [New Module] FindHDF5.cmake

[Brad King]

Will Dicharry wrote:
> What is the convention for keeping a macro out of the public interface?

Leave it out of the documentation and name it with a '_hdf5_' prefix
(starting in '_').

-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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [New Module] FindHDF5.cmake

[John R. Cary]

I am a real newbie here (exploring cmake) so my words should be taken
with a grain of salt.  But we find (in our current autotools
setup), that it is good to have a flag that tells one whether the hdf5 was
compiled with --enable-parallel.

John Cary

Will Dicharry wrote:

Brad King wrote:

Will Dicharry wrote:
Sorry for the month of delay, but I've addressed Mike Jackson's 
concerns

below and I think I'm close to having the HDF5 find module ready for
submission.


Excellent.  I have a few comments from quickly glancing at them, but
I don't have time for thorough testing.  Overall it looks good.


There are two modules attached to this message: The FindHDF5.cmake
module and an AdjustLibraryVariables.cmake module, which is essentially
a copy of what the FindQt4 module does.  It seems useful enough to
incorporate into the CMake Modules, and I can maintain it if you need a
maintainer.


I'd like to choose a better name for AdjustLibraryVariables.  Perhaps
"SelectLibraryConfigurations"?  Does it have all the functionality 
needed

to update FindQt4 to use it too (you don't need to do this but it should
be easy for the FindQt4 maintainer to do it)?


I agree, SelectLibraryConfigurations is better.  I'll rename it.  It 
looks like I need to set ${basename}_LIBRARIES (plural) too in order 
for the Qt4 module to use it, I'll go ahead and do that.




The find_path and find_library calls need some tweaking.  Please read
the documentation of these commands to distinguish the cases of PATHS
and HINTS keywords.  The PATHS should only be last-resort guesses.
The HINTS should be locations computed from the system, such as those
reported by the hdf5 compiler wrapper tools.  Also, paths like

  /usr/local/include
  /usr/include

are searched automatically and need not be listed.



I'll clean that up, I think the only path I'm specifying that should 
be in the PATH section is the $HOME/.local/ guess.  It seems 
everything else should be a HINT.  Thanks for the tip.



How I addressed Mike Jackson's concerns is addressed in the module
documentation at the top of the file, please let me know if anyone has
any other concerns.


Try placing these modules in the CMake/Modules source tree and running

  cmake --help-module FindHDF5
  cmake --help-module AdjustLibraryVariables

to make sure the documentation formats correctly.  Also, any macro in
the public interface of the module should be documented using a format
similar to the CMake command documentation.


What is the convention for keeping a macro out of the public interface?

Thanks for your help,
Will



Thanks,
-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://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] [New Module] FindHDF5.cmake

[Will Dicharry]

John R. Cary wrote:

I am a real newbie here (exploring cmake) so my words should be taken
with a grain of salt.  But we find (in our current autotools
setup), that it is good to have a flag that tells one whether the hdf5 was
compiled with --enable-parallel.


I agree that would be useful.  I *think* HDF5 will name the wrapper 
compilers h5pcc or h5pc++ (rather than h5cc) if HDF5 was compiled with 
collective IO support, so I could make a guess based on that.  Does 
anyone see a problem with this approach?


Thanks,
Will



John Cary

Will Dicharry wrote:

Brad King wrote:

Will Dicharry wrote:
Sorry for the month of delay, but I've addressed Mike Jackson's 
concerns

below and I think I'm close to having the HDF5 find module ready for
submission.


Excellent.  I have a few comments from quickly glancing at them, but
I don't have time for thorough testing.  Overall it looks good.


There are two modules attached to this message: The FindHDF5.cmake
module and an AdjustLibraryVariables.cmake module, which is essentially
a copy of what the FindQt4 module does.  It seems useful enough to
incorporate into the CMake Modules, and I can maintain it if you need a
maintainer.


I'd like to choose a better name for AdjustLibraryVariables.  Perhaps
"SelectLibraryConfigurations"?  Does it have all the functionality 
needed

to update FindQt4 to use it too (you don't need to do this but it should
be easy for the FindQt4 maintainer to do it)?


I agree, SelectLibraryConfigurations is better.  I'll rename it.  It 
looks like I need to set ${basename}_LIBRARIES (plural) too in order 
for the Qt4 module to use it, I'll go ahead and do that.




The find_path and find_library calls need some tweaking.  Please read
the documentation of these commands to distinguish the cases of PATHS
and HINTS keywords.  The PATHS should only be last-resort guesses.
The HINTS should be locations computed from the system, such as those
reported by the hdf5 compiler wrapper tools.  Also, paths like

  /usr/local/include
  /usr/include

are searched automatically and need not be listed.



I'll clean that up, I think the only path I'm specifying that should 
be in the PATH section is the $HOME/.local/ guess.  It seems 
everything else should be a HINT.  Thanks for the tip.



How I addressed Mike Jackson's concerns is addressed in the module
documentation at the top of the file, please let me know if anyone has
any other concerns.


Try placing these modules in the CMake/Modules source tree and running

  cmake --help-module FindHDF5
  cmake --help-module AdjustLibraryVariables

to make sure the documentation formats correctly.  Also, any macro in
the public interface of the module should be documented using a format
similar to the CMake command documentation.


What is the convention for keeping a macro out of the public interface?

Thanks for your help,
Will



Thanks,
-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://www.cmake.org/mailman/listinfo/cmake





--
Will Dicharry
Software Developer
Stellar Science Ltd Co


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] [New Module] FindHDF5.cmake

[Brad King]

Will Dicharry wrote:

John R. Cary wrote:

I am a real newbie here (exploring cmake) so my words should be taken
with a grain of salt.  But we find (in our current autotools
setup), that it is good to have a flag that tells one whether the hdf5 
was

compiled with --enable-parallel.


I agree that would be useful.  I *think* HDF5 will name the wrapper 
compilers h5pcc or h5pc++ (rather than h5cc) if HDF5 was compiled with 
collective IO support, so I could make a guess based on that.  Does 
anyone see a problem with this approach?


John, how do autotools detect this?

Thanks,
-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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [New Module] FindHDF5.cmake

[Brad King]

John R. Cary wrote:
> Brad King wrote:
>> John, how do autotools detect this?
> 
> hdf5par=`grep "HAVE_PARALLEL 1" $HDF5_INCDIR/H5config.h`
> 
> I suppose there are other ways, but we have been doing this through
> several versions of hdf5.

Great, thanks John.

Will, you should be able to use the file(STRINGS) command
to grep through H5config.h after finding it.

-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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] [New Module] FindHDF5.cmake

[Will Dicharry]

Brad King wrote:

John R. Cary wrote:

Brad King wrote:

John, how do autotools detect this?

hdf5par=`grep "HAVE_PARALLEL 1" $HDF5_INCDIR/H5config.h`

I suppose there are other ways, but we have been doing this through
several versions of hdf5.


Great, thanks John.

Will, you should be able to use the file(STRINGS) command
to grep through H5config.h after finding it.


Great!  I also added a call to find the h5diff tool for regression 
testing per James Sutherland's earlier request.


--Will

--
Will Dicharry
Software Developer
Stellar Science Ltd Co


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] pg compilers on the Cary XT4

[Will Dicharry]

Responses inline...

I'm reposting this to the CMake mailing list so someone can correct me 
if I'm wrong, it looks like your message went only to me.


John R. Cary wrote:

Will Dicharry wrote:

John R. Cary wrote:

which is basically Linux.

Building a project with pgcc/pgCC.


All flags are empty:

CMAKE_CXX_COMPILER   
/opt/pgi/8.0.4/linux86-64/8.0-4/bin/pgCC
CMAKE_CXX_FLAGS   

CMAKE_CXX_FLAGS_DEBUG 

CMAKE_CXX_FLAGS_MINSIZEREL

CMAKE_CXX_FLAGS_RELEASE   


CMAKE_CXX_FLAGS_RELWITHDEBINFO
Where should I add these?


For the XT4, the CNL backend no longer requires a cross compile. We 
had a discussion on the list about this last month, and for setting 
the compilers I believe the consensus was to either:


1.  Set them as environment variables.  CMake will check the value of 
the environment variables CC, CXX, and FC for the names of the C, C++, 
and Fortran compilers respectively.


2. Use cmake -C to


Thanks, Will.

I am getting the compiler set using 'CC=pgcc CXX=pgCC' in my environment,
but then the FLAGS variables are empty.





Another question: The default builds seem to be DEBUG,
MINSIZEREL, RELEASE, RELWITHDEBINFO.  Suppose I wanted
to define a new kind of build, e.g., PERFORMANCE.
How can I go about doing this?


When using the makefile generator, you can define a new build type by 
setting it in the CMAKE_BUILD_TYPE variable and defining language 
flags for that type, so you could do something like:


set( CMAKE_BUILD_TYPE PERFORMANCE )
set( CMAKE_C_FLAGS_PERFORMANCE "-O3" )
set( CMAKE_CXX_FLAGS_PERFORMANCE "-O3" )

take a look at http://www.cmake.org/Wiki/CMake_Useful_Variables in the 
CMAKE_BUILD_TYPE section.


Hope this helps, 


It helps alot!  Perhaps I just need to be directed to some reading 
material, even though

I have been googling quite a bit.

I would like to reuse these flags over many projects, and so I am hoping 
I can
put them in a file in my CMake subdir, which is actually an svn 
external, and be reused

across multiple projects.

 From my short experience with CMake, it seems that once one has determined
an OS/Compiler option, cmake looks for .cmake under 
Modules/Compiler,

then for -.cmake under Modules/Platform, with each able to
add to or overwrite the previous.

Is that correct?


I /think/ that is correct, although someone more familiar with CMake's 
startup procedure may be able to correct me.




If I want to override, then I assume I could add a file 
-.cmake in a directory
of my own choosing, but then I have to tell cmake where to look for my 
override files.


Is that correct?


I think the best way to override flags is to do it from your 
CMakeLists.txt project files (or through files included by them so you 
can use your externals scheme).  The - files are used to 
initialize the flags, you can modify them at configure time from your 
CMakeLists.txt files.  If you want to override them completely, you can 
do something like


set( CMAKE_CXX_FLAGS_ "-f1 -f2..." )

If you want to append to what CMake starts off with, you can do

set( CMAKE_CXX_FLAGS_ "${CMAKE_CXX_FLAGS_} -f1 -f2..." )



How to I tell cmake that I want it to look in another directory?

Thanks.John







--
Will Dicharry
Software Developer
Stellar Science Ltd Co


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] [New Module] FindHDF5.cmake

[Will Dicharry]

Brad King wrote:

John R. Cary wrote:

Brad King wrote:

John, how do autotools detect this?

hdf5par=`grep "HAVE_PARALLEL 1" $HDF5_INCDIR/H5config.h`

I suppose there are other ways, but we have been doing this through
several versions of hdf5.


Great, thanks John.

Will, you should be able to use the file(STRINGS) command
to grep through H5config.h after finding it.



John,

What version of HDF5 are you using?  It looks like H5config.h doesn't 
exists in 1.8.3.  I found the H5_HAVE_PARALLEL definition in H5pubconf.h 
for HDF5 1.8.3.


Thanks,
Will


-Brad



--
Will Dicharry
Software Developer
Stellar Science Ltd Co


smime.p7s
Description: S/MIME Cryptographic Signature
___
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] [New Module] FindHDF5.cmake

[John R. Cary]

Will Dicharry wrote:

Brad King wrote:

John R. Cary wrote:

Brad King wrote:

John, how do autotools detect this?

hdf5par=`grep "HAVE_PARALLEL 1" $HDF5_INCDIR/H5config.h`

I suppose there are other ways, but we have been doing this through
several versions of hdf5.


Great, thanks John.

Will, you should be able to use the file(STRINGS) command
to grep through H5config.h after finding it.



John,

What version of HDF5 are you using?  It looks like H5config.h doesn't 
exists in 1.8.3.  I found the H5_HAVE_PARALLEL definition in 
H5pubconf.h for HDF5 1.8.3. 


Hi Will,

That looks better:

Hi Will,  That looks better:

xena.cary$ cd hdf5-1.6.5/include
xena.cary$ grep -i parallel H5pubconf.h
/* Define if we have parallel support */
/* #undef H5_HAVE_PARALLEL */
xena.cary$ cd ../hdf5-1.8.2-ser/include
-bash: cd: ../hdf5-1.8.2-ser/include: No such file or directory
xena.cary$ cd ../../hdf5-1.8.2-ser/include
xena.cary$ grep -i parallel H5pubconf.h
/* Define if we have parallel support */
/* #undef H5_HAVE_PARALLEL */
xena.cary$ cd ../../hdf5-1.8.2-par/include
xena.cary$ grep -i parallel H5pubconf.h
/* Define if we have parallel support */
#define H5_HAVE_PARALLEL 1

available back through 1.6.5.

I was probably doing something for much older versions, as I now
see the full fragment:

if test $ac_cv_have_hdf5 = yes; then
 if test -f $HDF5_INCDIR/H5config.h; then
   hdf5par=`grep "HAVE_PARALLEL 1" $HDF5_INCDIR/H5config.h`
 elif test -f $HDF5_INCDIR/H5pubconf.h; then
   hdf5par=`grep "HAVE_PARALLEL 1" $HDF5_INCDIR/H5pubconf.h`
 fi
fi

which agrees with yours.

Best.John


--
Tech-X Corp., 5621 Arapahoe Ave, Suite A, Boulder CO 80303
c...@txcorp.com, p 303-448-0727, f 303-448-7756, NEW CELL 303-881-8572

___
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] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[Mike Jackson]

On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwell wrote:
> James Bigler wrote:
>> On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
>> mailto:bill.hoff...@kitware.com>> wrote:
>>
>>     James Bigler wrote:
>>
>>
>>         Well, I was using VS 2005 64 bit with SP 1.  I wonder if there
>>         is a similar bug or if there is something else going wrong
>>         such as what Marcus Hanwall described.
>>
>>
>>     I am not sure what your issue is, but I know I have done this many
>>     times...
>>
>>     -Bill
>>
>>
>> I checked the version numbers of the DLLs, and even checked the md5sum
>> and everything was the same between the dlls in the WinSxS folder and
>> the ones I'm distributing.  It failed on two clean systems without the
>> vcredist install.  I guess I'll run vcredist as Microsoft suggests and
>> see if I can trouble shoot later.
>>
>> It is a rather perplexing problem.
>>
> The link Bill supplied has all of the relevant information. In the
> "Community Discussion" section the second comment provides three
> possible workarounds. We are using the third of those when distributing
> Avogadro packages for Windows. The version mismatch in the manifests of
> the compiled executables and the manifest with the redistributable DLLs
> is what causes the issue.
>
> It seems that MS has no intention of fixing this issue. We have a clean
> VM where we test new installers, as occasionally this change was lost
> and the DLLs failed to load.
>
> Marcus

Ok, so I too have run into this problem. What is anyone doing to get
around this issue?

I would really like a solution that did NOT involve editing anything
from VC++ install as I would have to pass those instructions on to the
next Developer. Clinton's posting about including the VCRedist.exe in
the NSIS installer is OK by me. Is that what everyone else is doing?

Thanks
--
Mike Jackson
___
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] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[James Bigler]

On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson
wrote:

> On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwell wrote:
> > James Bigler wrote:
> >> On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
> >> mailto:bill.hoff...@kitware.com>> wrote:
> >>
> >> James Bigler wrote:
> >>
> >>
> >> Well, I was using VS 2005 64 bit with SP 1.  I wonder if there
> >> is a similar bug or if there is something else going wrong
> >> such as what Marcus Hanwall described.
> >>
> >>
> >> I am not sure what your issue is, but I know I have done this many
> >> times...
> >>
> >> -Bill
> >>
> >>
> >> I checked the version numbers of the DLLs, and even checked the md5sum
> >> and everything was the same between the dlls in the WinSxS folder and
> >> the ones I'm distributing.  It failed on two clean systems without the
> >> vcredist install.  I guess I'll run vcredist as Microsoft suggests and
> >> see if I can trouble shoot later.
> >>
> >> It is a rather perplexing problem.
> >>
> > The link Bill supplied has all of the relevant information. In the
> > "Community Discussion" section the second comment provides three
> > possible workarounds. We are using the third of those when distributing
> > Avogadro packages for Windows. The version mismatch in the manifests of
> > the compiled executables and the manifest with the redistributable DLLs
> > is what causes the issue.
> >
> > It seems that MS has no intention of fixing this issue. We have a clean
> > VM where we test new installers, as occasionally this change was lost
> > and the DLLs failed to load.
> >
> > Marcus
>
> Ok, so I too have run into this problem. What is anyone doing to get
> around this issue?
>
> I would really like a solution that did NOT involve editing anything
> from VC++ install as I would have to pass those instructions on to the
> next Developer. Clinton's posting about including the VCRedist.exe in
> the NSIS installer is OK by me. Is that what everyone else is doing?
>
> Thanks
> --
> Mike Jackson
>

I ended up linking against the static CRT library (/MT), but that's not for
everyone.
http://msdn.microsoft.com/en-us/library/ms235460.aspx

My next choice was going to be including the VCRedist.exe in the installer.
For some of the other projects at my company, this is what they do.

Here are some links I've been consulting on the subject of CRT library
(conflicts with multiple CRTs).
http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies
http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest

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] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[John Drescher]

On Thu, Aug 6, 2009 at 2:07 PM, Clinton Stimpson wrote:
> Bill Hoffman wrote:
>>
>> James Bigler wrote:
>>>
>>> I've just been bitten hard by this issue (many hours of frustration while
>>> attempting to run a demo application that should have "Just Worked" (TM) ).
>>>
>>> According to this page:
>>>
>>> http://support.microsoft.com/kb/326922
>>>
>>>
>>> "You should install these versions of the CRT on target computers by
>>> running the Vcredist_x86.exe application that is included with Visual
>>> Studio."  This is for the VS 2005 and 2008 versions of the C run-time
>>> libraries except for Windows 2000 in which case you need to install them in
>>> the system32 directory.
>>>
>>> I was dropping Msvcr80.dll and friends as per
>>> InstallRequiredSystemLibraries next to the binaries with ineffectual
>>> results.  It was really strange, because programs like Dependency Walker
>>> seemed to find them just fine.  It was only after running vcredist_x86.exe
>>> that I was able to run my programs properly.
>>>
>>> I though I should tell everyone that this method of distributing
>>> Msvcr80.dll and Msvcr90.dll next to your binaries is not supposed to work.
>>>  You must install them into the Windows Side by Side location (WinSxS) using
>>> the CRT.msm merge module or the vcredist_x86.exe that comes with Visual
>>> Studio.
>>>
>>> Now to try and get CPack to tell NSIS run the vcredist_x86.exe program
>>> during installation.
>>>
>>> Note, that many people might get lucky and have already installed a
>>> product that installed the right vcredist_x86.exe before installing your
>>> software.
>>>
>>
>> No this works fine However you may be running into this issue:
>>
>> "
>> Visual Studio 9 SP 1 has a bug that will cause trouble with cpack.
>>
>>
>> You can read about it here:
>>
>>
>> https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=361682
>>
>>
>> Basically, when you compile an executable or dll with VS9 SP1 it embeds
>> manifest information into the the exe or dll that does not match the
>> version information in the manifest files that SP 1 provides for
>> redistribution.
>> "
>>
>> We use the InstallRequiredSystemLibraries all the time without requiring
>> vcredist_x86.exe to be run.
>>
> There are some cases it doesn't work (3rd party libraries you can't compile
> yourself).
> I don't have two installs of the same Visual Studio versions with different
> service packs, so, here's what I do.
>
>   IF(MSVC80)
>     FIND_PROGRAM(MSVC_REDIST NAMES
> vcredist_${CMAKE_MSVC_ARCH}/vcredist_${CMAKE_MSVC_ARCH}.exe
>       PATHS
>
> "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\8.0;InstallDir]/../../SDK/v2.0/BootStrapper/Packages/"
>
> "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\8.0;InstallDir]/../../SDK/v2.0/BootStrapper/Packages/"
>       )
>     GET_FILENAME_COMPONENT(vcredist_name "${MSVC_REDIST}" NAME)
>     INSTALL(PROGRAMS ${MSVC_REDIST} COMPONENT Runtime DESTINATION bin)
>     SET(CPACK_NSIS_EXTRA_INSTALL_COMMANDS "ExecWait
> '\\\"$INSTDIRbin${vcredist_name}\\\"'")
>   ENDIF(MSVC80)
>
>

This worked for me after adding these lines before the above solution:

IF(CMAKE_CL_64)
 SET(CMAKE_MSVC_ARCH amd64)
   ELSE(CMAKE_CL_64)
 SET(CMAKE_MSVC_ARCH x86)
ENDIF(CMAKE_CL_64)

John
___
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] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[Mike Jackson]

On Thu, Aug 20, 2009 at 4:06 PM, James Bigler wrote:
> On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson 
> wrote:
>>
>> On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwell wrote:
>> > James Bigler wrote:
>> >> On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
>> >> mailto:bill.hoff...@kitware.com>> wrote:
>> >>
>> >>     James Bigler wrote:
>> >>
>> >>
>> >>         Well, I was using VS 2005 64 bit with SP 1.  I wonder if there
>> >>         is a similar bug or if there is something else going wrong
>> >>         such as what Marcus Hanwall described.
>> >>
>> >>
>> >>     I am not sure what your issue is, but I know I have done this many
>> >>     times...
>> >>
>> >>     -Bill
>> >>
>> >>
>> >> I checked the version numbers of the DLLs, and even checked the md5sum
>> >> and everything was the same between the dlls in the WinSxS folder and
>> >> the ones I'm distributing.  It failed on two clean systems without the
>> >> vcredist install.  I guess I'll run vcredist as Microsoft suggests and
>> >> see if I can trouble shoot later.
>> >>
>> >> It is a rather perplexing problem.
>> >>
>> > The link Bill supplied has all of the relevant information. In the
>> > "Community Discussion" section the second comment provides three
>> > possible workarounds. We are using the third of those when distributing
>> > Avogadro packages for Windows. The version mismatch in the manifests of
>> > the compiled executables and the manifest with the redistributable DLLs
>> > is what causes the issue.
>> >
>> > It seems that MS has no intention of fixing this issue. We have a clean
>> > VM where we test new installers, as occasionally this change was lost
>> > and the DLLs failed to load.
>> >
>> > Marcus
>>
>> Ok, so I too have run into this problem. What is anyone doing to get
>> around this issue?
>>
>> I would really like a solution that did NOT involve editing anything
>> from VC++ install as I would have to pass those instructions on to the
>> next Developer. Clinton's posting about including the VCRedist.exe in
>> the NSIS installer is OK by me. Is that what everyone else is doing?
>>
>> Thanks
>> --
>> Mike Jackson
>
> I ended up linking against the static CRT library (/MT), but that's not for
> everyone.
> http://msdn.microsoft.com/en-us/library/ms235460.aspx
>
> My next choice was going to be including the VCRedist.exe in the installer.
> For some of the other projects at my company, this is what they do.
>
> Here are some links I've been consulting on the subject of CRT library
> (conflicts with multiple CRTs).
> http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies
> http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
> http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest
>
> James
>

thanks for the links. Now my head is really spinning. I have VC2008
Express installed on WinXP SP3 and evidently the vcredist.exe is NOT
included with that version? At least I can not find it.  So I guess I
have to download it from MSDN (duh) and then manually set all the
paths and all that in oder to have cmake/NSIS find and include it in
the installer. And I thought deploying on OS X was a bit obtuse...

Mike
___
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] eclipse-cmake bug - more info

[Steve Mathers]

OK, I see the difference between the build directory and the build location 
now, even though in my project structure I inherited, they are the same 
directory - MMP

If I add the -C (path to makefile) option, I still get the error.

Im not moving the makefile.  My cmake file and the resulting Makefile are al 
sitting in MMP.  And remember, when I call make form the shell terminal, it 
always works, its just when make is invoked from within eclipse that it doesnt.

I notice that the syntax for specifying the build directory and makefile 
directory in your image are slightly different.  Is that intentional, and whats 
the significance? 

May I also ask:

what appears in the 'builders' config - I have two ticked items called 
something like 'cdt' and 'scanner'.  

Can you explain more what you mean with your first sentence?  Im not sure what 
you are saying exactly.

thanks again

Steve

- Original Message 
> From: Michael Jackson 
> To: Steve Mathers 
> Cc: cmake@cmake.org
> Sent: Thursday, 20 August, 2009 10:34:39 PM
> Subject: Re: [CMake] eclipse-cmake bug - more info
> 
> I think the problem is that Eclipse's project directory for mdc is basically 
> the 
> top level of your mdc project and NOT your MMP build directory. By using the 
> -C 
> Path/to/Dir/with/Makefile option to make you are telling "make" to look in 
> your 
> build directory for the makefile.
> Also, makefiles that are produced by CMake are NOT portable. Period. So you 
> cannot take a CMake generated Makefile and move it somewhere else.
> 
>   Here is a screen shot of my build settings. Hope it helps.
> 
> 
> _
> Mike Jackson  mike.jack...@bluequartz.net
> BlueQuartz Softwarewww.bluequartz.net
> Principal Software Engineer  Dayton, Ohio
> 
> On Aug 20, 2009, at 12:11 AM, Steve Mathers wrote:
> 
> > Yep, Makefile based project.   the project originally came with a Makefile 
> that didnt do incremental builds, which was driving me nuts, so I figured I 
> would replace that Makefile with one created by CMake.   I just overwrote the 
> original Makefile with one produced by CMake.
> > 
> > 
> > In your example below, my build directory is 'MMP' rather than 'Build', but 
> otherwise the same.
> > 
> > please see this image:
> > 
> > 
> http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.cdt.doc.user/reference/cdt_u_prop_build_settings_steps.htm
> > 
> > -  My builder type is 'external builder' and I dont have the option of 
> changing that, presumably since it is a makefile project.
> > - I have default build command unticked
> > - my build command is simply - 'make'
> > - I have generate makefiles automatically unticked.
> > - my build location build directory is ${workspace_loc:/mdc/MMP}
> > 
> > The build still fails in the same way whether I include the build location 
> > in 
> the actual 'build command' string or not (presumably it is set by the build 
> location paramter at the bottom)
> > 
> > 
> > thanks
> > 
> > Steve
> > 
> > 
> > 
> > - Original Message 
> >> From: Mike Jackson 
> >> To: Steve Mathers 
> >> Cc: cmake@cmake.org
> >> Sent: Thursday, 20 August, 2009 11:33:56 AM
> >> Subject: Re: [CMake] CMake Digest, Vol 64, Issue 50
> >> 
> >> Couple more questions just to be clear.
> >> 
> >> Did you choose to build a "Makefile" based Eclipse project when you
> >> created your project? If you just selected a "C++" project then
> >> eclipse is trying to create its own makefiles for your project.
> >> 
> >> Are you using an "out of source build" for your project? For example,
> >> do you have a "Build" directory within your project directory? Let's
> >> say for example that you have created a "Build" directory inside your
> >> project directory, then if you right click on the project in the C++
> >> Projects view, and select properties. Then Select "Build", there is an
> >> option to use the built in "make" or select your own command. Make
> >> what ever selection is necessary to enable the use of your own "make
> >> command". That command should be:
> >> 
> >> make -C ${workspace_loc}/mdc/Build VERBOSE=1
> >> 
> >> Then you can manually invoke the build for your project and see what 
> >> happens.
> >> 
> >> _
> >> Mike Jackson  mike.jack...@bluequartz.net
> >> BlueQuartz Softwarewww.bluequartz.net
> >> Principal Software Engineer  Dayton, Ohio
> >> 
> >> 
> >> 
> >> 
> >> On Wed, Aug 19, 2009 at 8:31 PM, Steve Matherswrote:
> >>> Hi Michael.  that option is what I am already doing, which is why I am
> >> confused.  'make' from the terminal works great, 'make' from eclipse craps 
> out.
> >>> 
> >>> I tried running eclipse from the terminal, and it didnt help.
> >>> 
> >>> I noticed something else strange
> >>> 
> >>> here is the output from eclipse once I have done a make from the terminal,
> >

[CMake] Pre-Compiled Headers

[ML]

Hi All,

I need to use a pre-compiled header.

I think that I recall that CMake is not yet equipped to handle this.

I found thought a Google search that SET_SOURCE_FILES_PROPERTIES might  
be the way to go.


Has anyone implemented PCH and have an example, advice, etc?

Thanks!
-Jason

___
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] Pre-Compiled Headers

[John Drescher]

On Thu, Aug 20, 2009 at 5:25 PM, ML wrote:
> Hi All,
>
> I need to use a pre-compiled header.
>
> I think that I recall that CMake is not yet equipped to handle this.
>
> I found thought a Google search that SET_SOURCE_FILES_PROPERTIES might be
> the way to go.
>
> Has anyone implemented PCH and have an example, advice, etc?
>

I do this for my Visual Studio builds with a macro.

#

macro( LA_PCH_SUPPORT ProjectName )
if (MSVC)
   if (USE_MSVC_PCH)

   set_source_files_properties(${ProjectName}PCH.cxx
   PROPERTIES
   COMPILE_FLAGS "/Yc${ProjectName}PCH.h"
   )
   foreach( src_file ${${ProjectName}_SRCS} )
   set_source_files_properties(
   ${src_file}
   PROPERTIES
   COMPILE_FLAGS "/Yu${ProjectName}PCH.h"
   )
   endforeach( src_file ${${ProjectName}_SRCS} )

   list(APPEND ${ProjectName}_SRCS ${ProjectName}PCH.cxx)
   list(APPEND ${ProjectName}_EXT_HDRS ${ProjectName}PCH.h)

   endif(USE_MSVC_PCH)
endif (MSVC)
endmacro (LA_PCH_SUPPORT)


Then its usage in a project named laGUI

SET( laGUI_SRCS
   ./src/laMultiViewFrameMgr.cxx
   ./src/VTK2dWidget.cpp
   ./src/laCentralWidget.cxx
   ./src/laImageSliceView.cxx
   ./src/laWLWidget.cxx
   ./src/laTableWidget.cxx
   ./src/laPipelineWidget.cxx
   ./src/ImageSliceViewer.cxx
   ./src/InteractorObserver.cxx
   ./src/laVTKInteractorStyleImage2D.cxx
   ./src/laVTKCommandImage2D.cxx
   ./src/la2DView.cxx
   ./src/la3DView.cxx
)

SET( laGUI_EXT_HDRS
   ./Include/InteractorObserver.h
   ./Include/laVTKInteractorStyleImage2D.h
   ./Include/laVTKCommandImage2D.h
)

SET( laGUI_MOC_HDRS
   ./Include/ImageSliceViewer.h
   ./Include/laMultiViewFrameMgr.h
   ./Include/VTK2dWidget.h
   ./Include/laCentralWidget.h
   ./Include/laImageSliceView.h
   ./Include/laWLWidget.h
   ./Include/laTableWidget.h
   ./Include/laPipelineWidget.h
   ./Include/la2DView.h
   ./Include/la3DView.h
)

#Add precompiled header support
LA_PCH_SUPPORT(laGUI)


Then externally create

laGUIPCH.cxx
laGUIPCH.h

in the same folder as the CMakeLists.txt file for the project.

John
___
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] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[David Cole]

Hold on there...

The Express editions are not meant to build redistributable binaries.
They're meant for personal use: i.e. -- each user compiles his own code. I'm
pretty sure it's a violation of the Express edition license agreement to
build binaries for other people. You need at least the "Standard" edition of
VS to get that capability.


HTH,
David


On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson
wrote:

> On Thu, Aug 20, 2009 at 4:06 PM, James Bigler
> wrote:
> > On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson <
> mike.jack...@bluequartz.net>
> > wrote:
> >>
> >> On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwell
> wrote:
> >> > James Bigler wrote:
> >> >> On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
> >> >> mailto:bill.hoff...@kitware.com>> wrote:
> >> >>
> >> >> James Bigler wrote:
> >> >>
> >> >>
> >> >> Well, I was using VS 2005 64 bit with SP 1.  I wonder if
> there
> >> >> is a similar bug or if there is something else going wrong
> >> >> such as what Marcus Hanwall described.
> >> >>
> >> >>
> >> >> I am not sure what your issue is, but I know I have done this
> many
> >> >> times...
> >> >>
> >> >> -Bill
> >> >>
> >> >>
> >> >> I checked the version numbers of the DLLs, and even checked the
> md5sum
> >> >> and everything was the same between the dlls in the WinSxS folder and
> >> >> the ones I'm distributing.  It failed on two clean systems without
> the
> >> >> vcredist install.  I guess I'll run vcredist as Microsoft suggests
> and
> >> >> see if I can trouble shoot later.
> >> >>
> >> >> It is a rather perplexing problem.
> >> >>
> >> > The link Bill supplied has all of the relevant information. In the
> >> > "Community Discussion" section the second comment provides three
> >> > possible workarounds. We are using the third of those when
> distributing
> >> > Avogadro packages for Windows. The version mismatch in the manifests
> of
> >> > the compiled executables and the manifest with the redistributable
> DLLs
> >> > is what causes the issue.
> >> >
> >> > It seems that MS has no intention of fixing this issue. We have a
> clean
> >> > VM where we test new installers, as occasionally this change was lost
> >> > and the DLLs failed to load.
> >> >
> >> > Marcus
> >>
> >> Ok, so I too have run into this problem. What is anyone doing to get
> >> around this issue?
> >>
> >> I would really like a solution that did NOT involve editing anything
> >> from VC++ install as I would have to pass those instructions on to the
> >> next Developer. Clinton's posting about including the VCRedist.exe in
> >> the NSIS installer is OK by me. Is that what everyone else is doing?
> >>
> >> Thanks
> >> --
> >> Mike Jackson
> >
> > I ended up linking against the static CRT library (/MT), but that's not
> for
> > everyone.
> > http://msdn.microsoft.com/en-us/library/ms235460.aspx
> >
> > My next choice was going to be including the VCRedist.exe in the
> installer.
> > For some of the other projects at my company, this is what they do.
> >
> > Here are some links I've been consulting on the subject of CRT library
> > (conflicts with multiple CRTs).
> >
> http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies
> >
> http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
> >
> http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest
> >
> > James
> >
>
> thanks for the links. Now my head is really spinning. I have VC2008
> Express installed on WinXP SP3 and evidently the vcredist.exe is NOT
> included with that version? At least I can not find it.  So I guess I
> have to download it from MSDN (duh) and then manually set all the
> paths and all that in oder to have cmake/NSIS find and include it in
> the installer. And I thought deploying on OS X was a bit obtuse...
>
> Mike
> ___
> 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] Pre-Compiled Headers

[John Drescher]

On Thu, Aug 20, 2009 at 5:25 PM, ML wrote:
> Hi All,
>
> I need to use a pre-compiled header.
>
> I think that I recall that CMake is not yet equipped to handle this.
>
> I found thought a Google search that SET_SOURCE_FILES_PROPERTIES might be
> the way to go.
>
> Has anyone implemented PCH and have an example, advice, etc?
>
> Thanks!
> -Jason
>
> ___
> 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
>

I gave you my Visual Studio solution.

There is also

http://www.vtk.org/Bug/view.php?id=1260

I actually do not bother on linux because using ccache reduces the
compile times enough not to have to worry about this.

John
___
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] Pre-Compiled Headers

[ML]

John,

Awesome, thanks for both of the e-mails.

-Jason

On Aug 20, 2009, at 2:29 PM, John Drescher wrote:

On Thu, Aug 20, 2009 at 5:25 PM, ML  
wrote:

Hi All,

I need to use a pre-compiled header.

I think that I recall that CMake is not yet equipped to handle this.

I found thought a Google search that SET_SOURCE_FILES_PROPERTIES  
might be

the way to go.

Has anyone implemented PCH and have an example, advice, etc?



I do this for my Visual Studio builds with a macro.

#

macro( LA_PCH_SUPPORT ProjectName )
if (MSVC)
  if (USE_MSVC_PCH)

  set_source_files_properties(${ProjectName}PCH.cxx
  PROPERTIES
  COMPILE_FLAGS "/Yc${ProjectName}PCH.h"
  )
  foreach( src_file ${${ProjectName}_SRCS} )
  set_source_files_properties(
  ${src_file}
  PROPERTIES
  COMPILE_FLAGS "/Yu${ProjectName}PCH.h"
  )
  endforeach( src_file ${${ProjectName}_SRCS} )

  list(APPEND ${ProjectName}_SRCS ${ProjectName}PCH.cxx)
  list(APPEND ${ProjectName}_EXT_HDRS ${ProjectName}PCH.h)

  endif(USE_MSVC_PCH)
endif (MSVC)
endmacro (LA_PCH_SUPPORT)


Then its usage in a project named laGUI

SET( laGUI_SRCS
  ./src/laMultiViewFrameMgr.cxx
  ./src/VTK2dWidget.cpp
  ./src/laCentralWidget.cxx
  ./src/laImageSliceView.cxx
  ./src/laWLWidget.cxx
  ./src/laTableWidget.cxx
  ./src/laPipelineWidget.cxx
  ./src/ImageSliceViewer.cxx
  ./src/InteractorObserver.cxx
  ./src/laVTKInteractorStyleImage2D.cxx
  ./src/laVTKCommandImage2D.cxx
  ./src/la2DView.cxx
  ./src/la3DView.cxx
)

SET( laGUI_EXT_HDRS
  ./Include/InteractorObserver.h
  ./Include/laVTKInteractorStyleImage2D.h
  ./Include/laVTKCommandImage2D.h
)

SET( laGUI_MOC_HDRS
  ./Include/ImageSliceViewer.h
  ./Include/laMultiViewFrameMgr.h
  ./Include/VTK2dWidget.h
  ./Include/laCentralWidget.h
  ./Include/laImageSliceView.h
  ./Include/laWLWidget.h
  ./Include/laTableWidget.h
  ./Include/laPipelineWidget.h
  ./Include/la2DView.h
  ./Include/la3DView.h
)

#Add precompiled header support
LA_PCH_SUPPORT(laGUI)


Then externally create

laGUIPCH.cxx
laGUIPCH.h

in the same folder as the CMakeLists.txt file for the project.

John


___
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] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[j s]

I don't believe that to be the case with Visual Express 2008.  I don't know
how previous editions work.
**
*Can I use Express Editions for commercial use?*

   1.

   Yes, there are no licensing restrictions for applications built using
   Visual Studio Express Editions.

http://www.microsoft.com/express/support/faq/

Juan



On Thu, Aug 20, 2009 at 4:33 PM, David Cole  wrote:

> Hold on there...
>
> The Express editions are not meant to build redistributable binaries.
> They're meant for personal use: i.e. -- each user compiles his own code. I'm
> pretty sure it's a violation of the Express edition license agreement to
> build binaries for other people. You need at least the "Standard" edition of
> VS to get that capability.
>
>
> HTH,
> David
>
>
> On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson  > wrote:
>
>>  On Thu, Aug 20, 2009 at 4:06 PM, James Bigler
>> wrote:
>> > On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson <
>> mike.jack...@bluequartz.net>
>> > wrote:
>> >>
>> >> On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwell
>> wrote:
>> >> > James Bigler wrote:
>> >> >> On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
>> >> >> mailto:bill.hoff...@kitware.com>> wrote:
>> >> >>
>> >> >> James Bigler wrote:
>> >> >>
>> >> >>
>> >> >> Well, I was using VS 2005 64 bit with SP 1.  I wonder if
>> there
>> >> >> is a similar bug or if there is something else going wrong
>> >> >> such as what Marcus Hanwall described.
>> >> >>
>> >> >>
>> >> >> I am not sure what your issue is, but I know I have done this
>> many
>> >> >> times...
>> >> >>
>> >> >> -Bill
>> >> >>
>> >> >>
>> >> >> I checked the version numbers of the DLLs, and even checked the
>> md5sum
>> >> >> and everything was the same between the dlls in the WinSxS folder
>> and
>> >> >> the ones I'm distributing.  It failed on two clean systems without
>> the
>> >> >> vcredist install.  I guess I'll run vcredist as Microsoft suggests
>> and
>> >> >> see if I can trouble shoot later.
>> >> >>
>> >> >> It is a rather perplexing problem.
>> >> >>
>> >> > The link Bill supplied has all of the relevant information. In the
>> >> > "Community Discussion" section the second comment provides three
>> >> > possible workarounds. We are using the third of those when
>> distributing
>> >> > Avogadro packages for Windows. The version mismatch in the manifests
>> of
>> >> > the compiled executables and the manifest with the redistributable
>> DLLs
>> >> > is what causes the issue.
>> >> >
>> >> > It seems that MS has no intention of fixing this issue. We have a
>> clean
>> >> > VM where we test new installers, as occasionally this change was lost
>> >> > and the DLLs failed to load.
>> >> >
>> >> > Marcus
>> >>
>> >> Ok, so I too have run into this problem. What is anyone doing to get
>> >> around this issue?
>> >>
>> >> I would really like a solution that did NOT involve editing anything
>> >> from VC++ install as I would have to pass those instructions on to the
>> >> next Developer. Clinton's posting about including the VCRedist.exe in
>> >> the NSIS installer is OK by me. Is that what everyone else is doing?
>> >>
>> >> Thanks
>> >> --
>> >> Mike Jackson
>> >
>> > I ended up linking against the static CRT library (/MT), but that's not
>> for
>> > everyone.
>> > http://msdn.microsoft.com/en-us/library/ms235460.aspx
>> >
>> > My next choice was going to be including the VCRedist.exe in the
>> installer.
>> > For some of the other projects at my company, this is what they do.
>> >
>> > Here are some links I've been consulting on the subject of CRT library
>> > (conflicts with multiple CRTs).
>> >
>> http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies
>> >
>> http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
>> >
>> http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest
>> >
>> > James
>> >
>>
>> thanks for the links. Now my head is really spinning. I have VC2008
>> Express installed on WinXP SP3 and evidently the vcredist.exe is NOT
>> included with that version? At least I can not find it.  So I guess I
>> have to download it from MSDN (duh) and then manually set all the
>> paths and all that in oder to have cmake/NSIS find and include it in
>> the installer. And I thought deploying on OS X was a bit obtuse...
>>
>> Mike
>>  ___
>> 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
>

Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[David Cole]

Thanks for the info That's what I get for expressing what I think are
facts from my flawed human memory. (Perhaps it was a fact with Express 2005
editions when I first read the licenses long ago...)

Sorry for the blip,
David


On Thu, Aug 20, 2009 at 5:40 PM, j s  wrote:

> I don't believe that to be the case with Visual Express 2008.  I don't know
> how previous editions work.
> **
> *Can I use Express Editions for commercial use?*
>
>1.
>
>Yes, there are no licensing restrictions for applications built using
>Visual Studio Express Editions.
>
> http://www.microsoft.com/express/support/faq/
>
> Juan
>
>
>
> On Thu, Aug 20, 2009 at 4:33 PM, David Cole wrote:
>
>> Hold on there...
>>
>> The Express editions are not meant to build redistributable binaries.
>> They're meant for personal use: i.e. -- each user compiles his own code. I'm
>> pretty sure it's a violation of the Express edition license agreement to
>> build binaries for other people. You need at least the "Standard" edition of
>> VS to get that capability.
>>
>>
>> HTH,
>> David
>>
>>
>> On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson <
>> mike.jack...@bluequartz.net> wrote:
>>
>>>  On Thu, Aug 20, 2009 at 4:06 PM, James Bigler
>>> wrote:
>>> > On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson <
>>> mike.jack...@bluequartz.net>
>>> > wrote:
>>> >>
>>> >> On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwell
>>> wrote:
>>> >> > James Bigler wrote:
>>> >> >> On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
>>> >> >> mailto:bill.hoff...@kitware.com>>
>>> wrote:
>>> >> >>
>>> >> >> James Bigler wrote:
>>> >> >>
>>> >> >>
>>> >> >> Well, I was using VS 2005 64 bit with SP 1.  I wonder if
>>> there
>>> >> >> is a similar bug or if there is something else going wrong
>>> >> >> such as what Marcus Hanwall described.
>>> >> >>
>>> >> >>
>>> >> >> I am not sure what your issue is, but I know I have done this
>>> many
>>> >> >> times...
>>> >> >>
>>> >> >> -Bill
>>> >> >>
>>> >> >>
>>> >> >> I checked the version numbers of the DLLs, and even checked the
>>> md5sum
>>> >> >> and everything was the same between the dlls in the WinSxS folder
>>> and
>>> >> >> the ones I'm distributing.  It failed on two clean systems without
>>> the
>>> >> >> vcredist install.  I guess I'll run vcredist as Microsoft suggests
>>> and
>>> >> >> see if I can trouble shoot later.
>>> >> >>
>>> >> >> It is a rather perplexing problem.
>>> >> >>
>>> >> > The link Bill supplied has all of the relevant information. In the
>>> >> > "Community Discussion" section the second comment provides three
>>> >> > possible workarounds. We are using the third of those when
>>> distributing
>>> >> > Avogadro packages for Windows. The version mismatch in the manifests
>>> of
>>> >> > the compiled executables and the manifest with the redistributable
>>> DLLs
>>> >> > is what causes the issue.
>>> >> >
>>> >> > It seems that MS has no intention of fixing this issue. We have a
>>> clean
>>> >> > VM where we test new installers, as occasionally this change was
>>> lost
>>> >> > and the DLLs failed to load.
>>> >> >
>>> >> > Marcus
>>> >>
>>> >> Ok, so I too have run into this problem. What is anyone doing to get
>>> >> around this issue?
>>> >>
>>> >> I would really like a solution that did NOT involve editing anything
>>> >> from VC++ install as I would have to pass those instructions on to the
>>> >> next Developer. Clinton's posting about including the VCRedist.exe in
>>> >> the NSIS installer is OK by me. Is that what everyone else is doing?
>>> >>
>>> >> Thanks
>>> >> --
>>> >> Mike Jackson
>>> >
>>> > I ended up linking against the static CRT library (/MT), but that's not
>>> for
>>> > everyone.
>>> > http://msdn.microsoft.com/en-us/library/ms235460.aspx
>>> >
>>> > My next choice was going to be including the VCRedist.exe in the
>>> installer.
>>> > For some of the other projects at my company, this is what they do.
>>> >
>>> > Here are some links I've been consulting on the subject of CRT library
>>> > (conflicts with multiple CRTs).
>>> >
>>> http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies
>>> >
>>> http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
>>> >
>>> http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest
>>> >
>>> > James
>>> >
>>>
>>> thanks for the links. Now my head is really spinning. I have VC2008
>>> Express installed on WinXP SP3 and evidently the vcredist.exe is NOT
>>> included with that version? At least I can not find it.  So I guess I
>>> have to download it from MSDN (duh) and then manually set all the
>>> paths and all that in oder to have cmake/NSIS find and include it in
>>> the installer. And I thought deploying on OS X was a bit obtuse...
>>>
>>> Mike
>>>  ___
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware ope

Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[Mike Jackson]

So I "created" the proper paths within the VCExpress installation and
placed the downloaded vcredist_x86.exe file in there. CMake found it.
NSIS found it and included it. I ran my new installer on a "clean" XP
SP3 machine. Verified the vcredist.exe actually ran also. Tried to
launch an application and I still get an error that says the
application is not configured correctly.

Still lost and Confused.

Mike

On Thu, Aug 20, 2009 at 5:40 PM, j s wrote:
> I don't believe that to be the case with Visual Express 2008.  I don't know
> how previous editions work.
>
> Can I use Express Editions for commercial use?
>
> Yes, there are no licensing restrictions for applications built using Visual
> Studio Express Editions.
>
> http://www.microsoft.com/express/support/faq/
>
> Juan
>
>
>
> On Thu, Aug 20, 2009 at 4:33 PM, David Cole  wrote:
>>
>> Hold on there...
>> The Express editions are not meant to build redistributable binaries.
>> They're meant for personal use: i.e. -- each user compiles his own code. I'm
>> pretty sure it's a violation of the Express edition license agreement to
>> build binaries for other people. You need at least the "Standard" edition of
>> VS to get that capability.
>>
>>
>> HTH,
>> David
>>
>> On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson
>>  wrote:
>>>
>>> On Thu, Aug 20, 2009 at 4:06 PM, James Bigler
>>> wrote:
>>> > On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson
>>> > 
>>> > wrote:
>>> >>
>>> >> On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwell
>>> >> wrote:
>>> >> > James Bigler wrote:
>>> >> >> On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
>>> >> >> mailto:bill.hoff...@kitware.com>> wrote:
>>> >> >>
>>> >> >>     James Bigler wrote:
>>> >> >>
>>> >> >>
>>> >> >>         Well, I was using VS 2005 64 bit with SP 1.  I wonder if
>>> >> >> there
>>> >> >>         is a similar bug or if there is something else going wrong
>>> >> >>         such as what Marcus Hanwall described.
>>> >> >>
>>> >> >>
>>> >> >>     I am not sure what your issue is, but I know I have done this
>>> >> >> many
>>> >> >>     times...
>>> >> >>
>>> >> >>     -Bill
>>> >> >>
>>> >> >>
>>> >> >> I checked the version numbers of the DLLs, and even checked the
>>> >> >> md5sum
>>> >> >> and everything was the same between the dlls in the WinSxS folder
>>> >> >> and
>>> >> >> the ones I'm distributing.  It failed on two clean systems without
>>> >> >> the
>>> >> >> vcredist install.  I guess I'll run vcredist as Microsoft suggests
>>> >> >> and
>>> >> >> see if I can trouble shoot later.
>>> >> >>
>>> >> >> It is a rather perplexing problem.
>>> >> >>
>>> >> > The link Bill supplied has all of the relevant information. In the
>>> >> > "Community Discussion" section the second comment provides three
>>> >> > possible workarounds. We are using the third of those when
>>> >> > distributing
>>> >> > Avogadro packages for Windows. The version mismatch in the manifests
>>> >> > of
>>> >> > the compiled executables and the manifest with the redistributable
>>> >> > DLLs
>>> >> > is what causes the issue.
>>> >> >
>>> >> > It seems that MS has no intention of fixing this issue. We have a
>>> >> > clean
>>> >> > VM where we test new installers, as occasionally this change was
>>> >> > lost
>>> >> > and the DLLs failed to load.
>>> >> >
>>> >> > Marcus
>>> >>
>>> >> Ok, so I too have run into this problem. What is anyone doing to get
>>> >> around this issue?
>>> >>
>>> >> I would really like a solution that did NOT involve editing anything
>>> >> from VC++ install as I would have to pass those instructions on to the
>>> >> next Developer. Clinton's posting about including the VCRedist.exe in
>>> >> the NSIS installer is OK by me. Is that what everyone else is doing?
>>> >>
>>> >> Thanks
>>> >> --
>>> >> Mike Jackson
>>> >
>>> > I ended up linking against the static CRT library (/MT), but that's not
>>> > for
>>> > everyone.
>>> > http://msdn.microsoft.com/en-us/library/ms235460.aspx
>>> >
>>> > My next choice was going to be including the VCRedist.exe in the
>>> > installer.
>>> > For some of the other projects at my company, this is what they do.
>>> >
>>> > Here are some links I've been consulting on the subject of CRT library
>>> > (conflicts with multiple CRTs).
>>> >
>>> > http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies
>>> >
>>> > http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
>>> >
>>> > http://stackoverflow.com/questions/1265792/visual-studio-2005-security-updates-and-crt-dll-versions-in-manifest
>>> >
>>> > James
>>> >
>>>
>>> thanks for the links. Now my head is really spinning. I have VC2008
>>> Express installed on WinXP SP3 and evidently the vcredist.exe is NOT
>>> included with that version? At least I can not find it.  So I guess I
>>> have to download it from MSDN (duh) and then manually set all the
>>> paths and all that in oder to have cmake/NSIS find and include it in
>>> the installer. And I thought d

Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[j s]

Did you try the dependency walker (available via google) to see if there may
be any dll's you need to have in the same directory as the binary?

Regards,

Juan

On Thu, Aug 20, 2009 at 5:03 PM, Mike Jackson
wrote:

> So I "created" the proper paths within the VCExpress installation and
> placed the downloaded vcredist_x86.exe file in there. CMake found it.
> NSIS found it and included it. I ran my new installer on a "clean" XP
> SP3 machine. Verified the vcredist.exe actually ran also. Tried to
> launch an application and I still get an error that says the
> application is not configured correctly.
>
> Still lost and Confused.
>
> Mike
>
> On Thu, Aug 20, 2009 at 5:40 PM, j s wrote:
> > I don't believe that to be the case with Visual Express 2008.  I don't
> know
> > how previous editions work.
> >
> > Can I use Express Editions for commercial use?
> >
> > Yes, there are no licensing restrictions for applications built using
> Visual
> > Studio Express Editions.
> >
> > http://www.microsoft.com/express/support/faq/
> >
> > Juan
> >
> >
> >
> > On Thu, Aug 20, 2009 at 4:33 PM, David Cole 
> wrote:
> >>
> >> Hold on there...
> >> The Express editions are not meant to build redistributable binaries.
> >> They're meant for personal use: i.e. -- each user compiles his own code.
> I'm
> >> pretty sure it's a violation of the Express edition license agreement to
> >> build binaries for other people. You need at least the "Standard"
> edition of
> >> VS to get that capability.
> >>
> >>
> >> HTH,
> >> David
> >>
> >> On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson
> >>  wrote:
> >>>
> >>> On Thu, Aug 20, 2009 at 4:06 PM, James Bigler
> >>> wrote:
> >>> > On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson
> >>> > 
> >>> > wrote:
> >>> >>
> >>> >> On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwell
> >>> >> wrote:
> >>> >> > James Bigler wrote:
> >>> >> >> On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
> >>> >> >> mailto:bill.hoff...@kitware.com>>
> wrote:
> >>> >> >>
> >>> >> >> James Bigler wrote:
> >>> >> >>
> >>> >> >>
> >>> >> >> Well, I was using VS 2005 64 bit with SP 1.  I wonder if
> >>> >> >> there
> >>> >> >> is a similar bug or if there is something else going
> wrong
> >>> >> >> such as what Marcus Hanwall described.
> >>> >> >>
> >>> >> >>
> >>> >> >> I am not sure what your issue is, but I know I have done this
> >>> >> >> many
> >>> >> >> times...
> >>> >> >>
> >>> >> >> -Bill
> >>> >> >>
> >>> >> >>
> >>> >> >> I checked the version numbers of the DLLs, and even checked the
> >>> >> >> md5sum
> >>> >> >> and everything was the same between the dlls in the WinSxS folder
> >>> >> >> and
> >>> >> >> the ones I'm distributing.  It failed on two clean systems
> without
> >>> >> >> the
> >>> >> >> vcredist install.  I guess I'll run vcredist as Microsoft
> suggests
> >>> >> >> and
> >>> >> >> see if I can trouble shoot later.
> >>> >> >>
> >>> >> >> It is a rather perplexing problem.
> >>> >> >>
> >>> >> > The link Bill supplied has all of the relevant information. In the
> >>> >> > "Community Discussion" section the second comment provides three
> >>> >> > possible workarounds. We are using the third of those when
> >>> >> > distributing
> >>> >> > Avogadro packages for Windows. The version mismatch in the
> manifests
> >>> >> > of
> >>> >> > the compiled executables and the manifest with the redistributable
> >>> >> > DLLs
> >>> >> > is what causes the issue.
> >>> >> >
> >>> >> > It seems that MS has no intention of fixing this issue. We have a
> >>> >> > clean
> >>> >> > VM where we test new installers, as occasionally this change was
> >>> >> > lost
> >>> >> > and the DLLs failed to load.
> >>> >> >
> >>> >> > Marcus
> >>> >>
> >>> >> Ok, so I too have run into this problem. What is anyone doing to get
> >>> >> around this issue?
> >>> >>
> >>> >> I would really like a solution that did NOT involve editing anything
> >>> >> from VC++ install as I would have to pass those instructions on to
> the
> >>> >> next Developer. Clinton's posting about including the VCRedist.exe
> in
> >>> >> the NSIS installer is OK by me. Is that what everyone else is doing?
> >>> >>
> >>> >> Thanks
> >>> >> --
> >>> >> Mike Jackson
> >>> >
> >>> > I ended up linking against the static CRT library (/MT), but that's
> not
> >>> > for
> >>> > everyone.
> >>> > http://msdn.microsoft.com/en-us/library/ms235460.aspx
> >>> >
> >>> > My next choice was going to be including the VCRedist.exe in the
> >>> > installer.
> >>> > For some of the other projects at my company, this is what they do.
> >>> >
> >>> > Here are some links I've been consulting on the subject of CRT
> library
> >>> > (conflicts with multiple CRTs).
> >>> >
> >>> >
> http://stackoverflow.com/questions/1075050/howto-multiple-versions-of-msvcrt9-as-private-sxs-assemblies
> >>> >
> >>> >
> http://tedwvc.wordpress.com/2009/08/10/avoiding-problems-with-vc2005-sp1-security-update-kb971090/
> >>> >
> >>> >
> http://stackoverflow.com/questio

Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[Mike Jackson]

Yep. First thing I have tried, and have been using all day. I think I
may have tracked part of the problem down to a few things.

1: vcredist_x86.exe - There are multiple versions of this (all with
the same file name). You have to make sure you download the correct
version. I have VCExpress 2008 SP1. I was downloading the one for
VCExpress 2008.

2: I think I have ITK built as Debug and I am trying a "Release" build
of my main application suite. We all know that Debug and Release
builds in Windows-Land do not get along.

Boost may be another unknown (bjam.. yeech..). Far as I know I told
bjam to use a dynamically linked c runtime.

Expat, HDF5, Tiff all are built as static libraries using CMake so the
default there is to use a dynamic linked c runtime. So I think those
libraries are OK.

My own intermediate library (MXADataModel) is also built as a static
library and using CMake. So should be the same as Expat, HDF5 and Tif
from above.

Does not seem to be a redistributable package for the Debug versions
of the C/C++ runtime libs. Bummer.

Qt 4.5.1 is built as DLL's so I am hoping that will not hinder me as
everything else is built as Static libraries (to try and avoid DLL
hell .. )

ITK is currently rebuilding which will take another hour or so. I'll
report back when that is complete maybe with some good
_
Mike Jackson  mike.jack...@bluequartz.net

On Thu, Aug 20, 2009 at 6:57 PM, j s wrote:
> Did you try the dependency walker (available via google) to see if there may
> be any dll's you need to have in the same directory as the binary?
>
> Regards,
>
> Juan
>
> On Thu, Aug 20, 2009 at 5:03 PM, Mike Jackson 
> wrote:
>>
>> So I "created" the proper paths within the VCExpress installation and
>> placed the downloaded vcredist_x86.exe file in there. CMake found it.
>> NSIS found it and included it. I ran my new installer on a "clean" XP
>> SP3 machine. Verified the vcredist.exe actually ran also. Tried to
>> launch an application and I still get an error that says the
>> application is not configured correctly.
>>
>> Still lost and Confused.
>>
>> Mike
>>
>> On Thu, Aug 20, 2009 at 5:40 PM, j s wrote:
>> > I don't believe that to be the case with Visual Express 2008.  I don't
>> > know
>> > how previous editions work.
>> >
>> > Can I use Express Editions for commercial use?
>> >
>> > Yes, there are no licensing restrictions for applications built using
>> > Visual
>> > Studio Express Editions.
>> >
>> > http://www.microsoft.com/express/support/faq/
>> >
>> > Juan
>> >
>> >
>> >
>> > On Thu, Aug 20, 2009 at 4:33 PM, David Cole 
>> > wrote:
>> >>
>> >> Hold on there...
>> >> The Express editions are not meant to build redistributable binaries.
>> >> They're meant for personal use: i.e. -- each user compiles his own
>> >> code. I'm
>> >> pretty sure it's a violation of the Express edition license agreement
>> >> to
>> >> build binaries for other people. You need at least the "Standard"
>> >> edition of
>> >> VS to get that capability.
>> >>
>> >>
>> >> HTH,
>> >> David
>> >>
>> >> On Thu, Aug 20, 2009 at 5:11 PM, Mike Jackson
>> >>  wrote:
>> >>>
>> >>> On Thu, Aug 20, 2009 at 4:06 PM, James Bigler
>> >>> wrote:
>> >>> > On Thu, Aug 20, 2009 at 1:51 PM, Mike Jackson
>> >>> > 
>> >>> > wrote:
>> >>> >>
>> >>> >> On Thu, Aug 6, 2009 at 3:12 PM, Marcus D. Hanwell
>> >>> >> wrote:
>> >>> >> > James Bigler wrote:
>> >>> >> >> On Thu, Aug 6, 2009 at 12:10 PM, Bill Hoffman
>> >>> >> >> mailto:bill.hoff...@kitware.com>>
>> >>> >> >> wrote:
>> >>> >> >>
>> >>> >> >>     James Bigler wrote:
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>         Well, I was using VS 2005 64 bit with SP 1.  I wonder if
>> >>> >> >> there
>> >>> >> >>         is a similar bug or if there is something else going
>> >>> >> >> wrong
>> >>> >> >>         such as what Marcus Hanwall described.
>> >>> >> >>
>> >>> >> >>
>> >>> >> >>     I am not sure what your issue is, but I know I have done
>> >>> >> >> this
>> >>> >> >> many
>> >>> >> >>     times...
>> >>> >> >>
>> >>> >> >>     -Bill
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> I checked the version numbers of the DLLs, and even checked the
>> >>> >> >> md5sum
>> >>> >> >> and everything was the same between the dlls in the WinSxS
>> >>> >> >> folder
>> >>> >> >> and
>> >>> >> >> the ones I'm distributing.  It failed on two clean systems
>> >>> >> >> without
>> >>> >> >> the
>> >>> >> >> vcredist install.  I guess I'll run vcredist as Microsoft
>> >>> >> >> suggests
>> >>> >> >> and
>> >>> >> >> see if I can trouble shoot later.
>> >>> >> >>
>> >>> >> >> It is a rather perplexing problem.
>> >>> >> >>
>> >>> >> > The link Bill supplied has all of the relevant information. In
>> >>> >> > the
>> >>> >> > "Community Discussion" section the second comment provides three
>> >>> >> > possible workarounds. We are using the third of those when
>> >>> >> > distributing
>> >>> >> > Avogadro packages for Windows. The version mismatch in the
>> 

Re: [CMake] InstallRequiredSystemLibraries.cmake and Redistribution of the shared C runtime component in Visual C++

[Mike Jackson]

OK. Turns out it was ITK being compiled in Debug mode and then trying
to link against it with a Release build.

On to some comments that might help others:

VCExpress 2008 SP1 does NOT come with VCRedist_x86.exe. You will need
to download the correct version.
VCExpress 2008:


VCExpress 2008 SP1:


Double and Triple check that all your projects and sub projects have
all been compiled the same way (Debug vs Release) and all with the
same settings for the c/c++ runtime libraries.

In order to re-use Clinton's code I had to create a few directories:
C:\Program Files\Microsoft Visual Studio
9.0\SDK\v3.5\BootStrapper\Packages\vcredist_x86

needs to be created (so that it matches the VS2005 paths).

Next I created a Macro:

macro(_FIND_MSVC_REDIST VCVERS)
  message(STATUS "Looking for MSVC Redistributable Executable for MSVC
Version ${VCVERS}")
  set(SDKVERS "2.0")
  if(${VCVERS} EQUAL 8)
set(SDKVERS "2.0")
  endif()
  if(${VCVERS} EQUAL 9)
set(SDKVERS "3.5")
  endif()
  IF(MSVC${VCVERS}0)
FIND_PROGRAM(MSVC_REDIST NAMES
vcredist_${CMAKE_MSVC_ARCH}/vcredist_${CMAKE_MSVC_ARCH}.exe
  PATHS
  
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VCExpress\\${VCVERS}.0;InstallDir]/../../SDK/v${SDKVERS}/BootStrapper/Packages/"
  
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\VisualStudio\\${VCVERS}.0;InstallDir]/../../SDK/v${SDKVERS}/BootStrapper/Packages/"
  
"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\VisualStudio\\${VCVERS}.0;InstallDir]/../../SDK/v${SDKVERS}/BootStrapper/Packages/"
  )
GET_FILENAME_COMPONENT(vcredist_name "${MSVC_REDIST}" NAME)
INSTALL(PROGRAMS ${MSVC_REDIST} COMPONENT SupportFiles DESTINATION bin)
SET(CPACK_NSIS_EXTRA_INSTALL_COMMANDS "ExecWait
'\\\"$INSTDIRbin${vcredist_name}\\\"'")
message(STATUS "MSVC_REDIST: ${MSVC_REDIST}")
  ENDIF(MSVC${VCVERS}0)
endmacro()


The have the following:

if(MSVC80)
_FIND_MSVC_REDIST(8)
endif()

if(MSVC90)
_FIND_MSVC_REDIST(9)
endif()

I would like to add sometime in the future the correct command to run
the vcredist silently during the installation.

I think that is all. I would also like to thank everyone here for
their patience with me today. Also like to put in a word to the
VirtualBox guys at Sun. The make really nice FREE virtual machine
which allowed the quick testing of the installer on a "Clean" Windows
XP SP3 install. Thanks

_
Mike Jackson  mike.jack...@bluequartz.net

On Thu, Aug 20, 2009 at 7:05 PM, Mike
Jackson wrote:
> Yep. First thing I have tried, and have been using all day. I think I
> may have tracked part of the problem down to a few things.
>
> 1: vcredist_x86.exe - There are multiple versions of this (all with
> the same file name). You have to make sure you download the correct
> version. I have VCExpress 2008 SP1. I was downloading the one for
> VCExpress 2008.
>
> 2: I think I have ITK built as Debug and I am trying a "Release" build
> of my main application suite. We all know that Debug and Release
> builds in Windows-Land do not get along.
>
> Boost may be another unknown (bjam.. yeech..). Far as I know I told
> bjam to use a dynamically linked c runtime.
>
> Expat, HDF5, Tiff all are built as static libraries using CMake so the
> default there is to use a dynamic linked c runtime. So I think those
> libraries are OK.
>
> My own intermediate library (MXADataModel) is also built as a static
> library and using CMake. So should be the same as Expat, HDF5 and Tif
> from above.
>
> Does not seem to be a redistributable package for the Debug versions
> of the C/C++ runtime libs. Bummer.
>
> Qt 4.5.1 is built as DLL's so I am hoping that will not hinder me as
> everything else is built as Static libraries (to try and avoid DLL
> hell .. )
>
> ITK is currently rebuilding which will take another hour or so. I'll
> report back when that is complete maybe with some good
> _
> Mike Jackson                  mike.jack...@bluequartz.net
>
> On Thu, Aug 20, 2009 at 6:57 PM, j s wrote:
>> Did you try the dependency walker (available via google) to see if there may
>> be any dll's you need to have in the same directory as the binary?
>>
>> Regards,
>>
>> Juan
>>
>> On Thu, Aug 20, 2009 at 5:03 PM, Mike Jackson 
>> wrote:
>>>
>>> So I "created" the proper paths within the VCExpress installation and
>>> placed the downloaded vcredist_x86.exe file in there. CMake found it.
>>> NSIS found it and included it. I ran my new installer on a "clean" XP
>>> SP3 machine. Verified the vcredist.exe actually ran also. Tried to
>>> launch an application and I still get an error that says the
>>> application is not configured correctly.
>>>
>>> Still lost and Confused.
>>>

Re: [CMake] F90 and legacy F77

[James C. Sutherland]

All,

Thanks for the many suggestions.  I managed to subdue the one error  
message I got by adding some compiler flags (the --fdefault-real8 did  
the job, although I am not quite sure why because the statement it was  
giving errors on was dealing with integers).


Alin's suggestion of using the "-std=legacy" flag quieted most of the  
warnings.


Thanks again.

James


On Aug 20, 2009, at 12:17 PM, Alin M Elena wrote:


Hi James,

this is the option of gfortran that you want to look into.
-std=std
  Specify the standard to which the program is expected to  
conform,

which may be one of f95, f2003, f2008, gnu,
  or legacy.  The default value for std is gnu, which  
specifies a

superset of the Fortran 95 standard that
  includes all of the extensions supported by GNU Fortran,  
although

warnings will be given for obsolete
  extensions not recommended for use in new code.  The  
legacy value

is equivalent but without the warnings for
  obsolete extensions, and may be useful for old non-standard
programs.  The f95, f2003 and f2008 values specify
  strict conformance to the Fortran 95, Fortran 2003 and  
Fortran 2008

standards, respectively; errors are given
  for all extensions beyond the relevant language standard,  
and

warnings are given for the Fortran 77 features
  that are permitted but obsolescent in later standards.


A good compiler would select the type of the standard after the  
extension.


than you should look at this
set_source_files_properties(${src_dir}/SCF2.f90  PROPERTIES  
COMPILE_FLAGS

/Od)

if the code is too old 80's you may deal with pre fortran 77 and  
other special

extension that were never part of standard.

Alin

On Wednesday 19 August 2009 01:20:39 cmake-requ...@cmake.org wrote:

Message: 3
Date: Tue, 18 Aug 2009 15:39:14 -0600
From: "James C. Sutherland" 
Subject: [CMake] F90 and legacy F77
To: cmake Mailing List 
Message-ID: <1896503e-7a81-4517-8bcb-d11ae6db7...@utah.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

Is there a way to detect and use both F77 and F90 compilers?

I have some legacy F77 code that uses constructs that have been
deprecated/removed in F90.  I would like to compile those F77 files
with a F77 compiler, compile the F90 files with an F90 compiler, and
then link them with the F90 compiler.

How can this be done with CMake?

For example:
   foo.f   <-- F77 file
   bar.f90  <-- F90 file

I want something equivalent to
   g77 foo.f -o foo.o
   gfotran bar.f90 foo.o -o executable.x


--
  
__

 Without Questions there are no Answers!
  
__

 Mr  Alin M ELENA
 Irish Centre for High-End Computing -- www.ichec.ie
 The Design Tower, Trinity Technology & Enterprise Campus
 Grand Canal Quay,  Dublin 2, Ireland
 Tel:   +353 (0) 1 5241608 ext 29
 Fax: +353 (0) 1 7645845
 http://alin.elenaworld.net
 alin.el...@ichec.ie
 alinm.el...@gmail.com
  
__


--
  
__

 Without Questions there are no Answers!
  
__

 Mr  Alin M ELENA
 Irish Centre for High-End Computing -- www.ichec.ie
 The Design Tower, Trinity Technology & Enterprise Campus
 Grand Canal Quay,  Dublin 2, Ireland
 Tel:   +353 (0) 1 5241608 ext 29
 Fax: +353 (0) 1 7645845
 http://alin.elenaworld.net
 alin.el...@ichec.ie
 alinm.el...@gmail.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