[cmake-developers] regarding cMake support on windows I tanium platforms

[ajay bansal]

Hi All,

I want to create a Visual studio project (VS2008, c/c++) using this 
cMakeList.txt for i386, x64  Itanium platforms on windows. I found options for 
i386  x64 platforms in cmake GUI but there is nothing for Itanium platform.

- Does cmake support windows Itanium platform, if yes then please help me with 
the steps to build the same ?

- Is there any advanced options using which i can achieve the same

Best regards,
Ajay
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [CMake] Possible 'brief' output options for UnixMakefileGenerator

[Jesper Eskilson]

On 12/20/2010 01:01 AM, Campbell Barton wrote:

Hi, I'm STILL trying to have CMake makefiles replace Blender's hand
crafted makefiles.

Now the main sticking point with 2 other developers is they don't like
CMakes output, as its overly verbose.

I realize CMake doesn't need to bend to the whim of all users but
wondering if we could have something like  RULE_BRIEF_OUTPUT

Rather then printing progress and full path for all files it could
skip percentage and use a relative path for each C file.

I can try submitting a patch but would first like to know if this
would be acceptable.


I've submitted a bugreport about this: 
http://www.cmake.org/Bug/view.php?id=7062. It was submitted almost two 
years ago, so I'm not sure it is getting very much attention by the 
CMake people.


--
Jesper Eskilson
Developer
IAR Systems

___
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] FindMPI doesn't differentiate between languages

[Marcel Loose]

 On 19-12-2010 at 0:04, in message
a43e19d1-af96-4935-99fd-705a4cda7...@llnl.gov, Todd Gamblin
tgamb...@llnl.gov wrote: 
 Hey all,
 
 This has been brought up before (sort of) here:
 

http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/26533
 
 FindMPI doesn't currently give you the libraries, includes, etc. for

 different languages. MPI compilers can (and typically do) have
different 
 includes/libraries depending on the language you're using.  It was
noted 
 above that you don't get the fortran libraries for MPI using the
current 
 macro.  Another problem with the current setup is that you're also
likely to 
 inadvertently get the C++ includes with the current FindMPI, unless
you 
 explicitly disable them using things like -DOMPI_SKIP_MPICXX.  This
can get 
 you unwanted C++ symbols in your MPI libraries (because the MPI C++
interface 
 and headers suck, but that's a whole different story).
 
 I'd be interested in fixing this.  But I would like guidance on how
to do 
 it.  My inclination would be to make a new version that gives you not
just 
 MPI_FOUND, MPI_LIBRARIES, etc.. but MPI_LANG_FOUND,
MPI_LANG_LIBRARIES, 
 MPI_LANG_INCLUDE_PATH, etc.  If you read the thread above, someone
suggested 
 using components for this back in January, but that was left on the
table and 
 seems not to have been implemented.
 
 What's the best way to implement proper language support in the
FindMPI 
 module?
 
 -Todd

Hi Todd,

I think this is a good idea. You might consider taking into account
which languages are currently enabled, either explicitly with
enable_language() or implicitly with project().

Best regards,
Marcel Loose.



-- 
Marcel Loose
Senior Software Engineer, Computing Group RD, Astron, the Netherlands

___
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] execute_process spew test

[luxInteg]

Greetings

I tried an execute_process that  spits out a file. Llets call this  
${someDirectory}/someFile.

I then tried   to do a test like so 
  if( ${someDirectory}/someFile 1 )
  --- do something
endif( ${someDirectory}/someFile 1 )

but it does not seem to work

in  shell scripts{linux}   we can use   the following:-
 if  [-f  ${someDirectory}/someFile ] ;  do somehing
 or 
 if  [-r ${someDirectory}/someFile ];   do something else

advice on their equivalent in cmake scripts would be appreciated.

luxInteg
___
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] execute_process spew test

[Rolf Eike Beer]

 Greetings

 I tried an execute_process that  spits out a file. Llets call this
 ${someDirectory}/someFile.

 I then tried   to do a test like so
   if( ${someDirectory}/someFile 1 )
   --- do something
 endif( ${someDirectory}/someFile 1 )

 but it does not seem to work

 in  shell scripts{linux}   we can use   the following:-
  if  [-f  ${someDirectory}/someFile ] ;  do somehing
  or
  if  [-r ${someDirectory}/someFile ];   do something else

 advice on their equivalent in cmake scripts would be appreciated.

You should really start to read the man page.

===
  if(EXISTS file-name)
  if(EXISTS directory-name)

 True if the named file or directory exists. Behavior is well-defined only
for full paths.
===

Eike
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?

[David Cole]

On Sun, Dec 19, 2010 at 3:50 PM, Mike McQuaid m...@mikemcquaid.com wrote:

 On 16 December 2010 08:34, Andreas Mohr a...@lisas.de wrote:
  I'd like to know how to possibly detect this within CMake code.

 This works for me:
 INSTALL( CODE 
 IF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
 
 ENDIF( \${CMAKE_INSTALL_PREFIX} MATCHES .*/_CPack_Packages/.* )
  )

 However, you then need to put all your CMake logic in INSTALL(CODE
 ...) logic. Either later tonight or tomorrow I'll post my suggestions
 to this list for possible patches I will try and get included to
 improve this situation as INSTALL(CODE ...) escaping isn't trivial.

 --
 Mike McQuaid
 http://mikemcquaid.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



When you find yourself in the must escape too much situation in an
INSTALL(CODE scenario you should switch to writing out a script that you
then include with an INSTALL(SCRIPT command. They are absolutely equivalent,
except with CODE you specify the code inline when it does not need
significant escaping, or if it's just a line or two. If it does need lots of
escaping or is longer than 1-3 lines, I would say it should be the SCRIPT
form anyway.

And honestly, I think that Eric's suggestion of using a
CPACK_PROJECT_CONFIG_FILE is the way to go here. If you have one, CPack will
include it before running your install rules. You can use any sentinel you
like within that file: it will only ever be included by CPack, so if you're
in its context, then you know you're being run by CPack.


HTH,
David
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?

[Mike McQuaid]

On 20 December 2010 12:34, David Cole david.c...@kitware.com wrote:
 On Sun, Dec 19, 2010 at 3:50 PM, Mike McQuaid m...@mikemcquaid.com wrote:
 When you find yourself in the must escape too much situation in an
 INSTALL(CODE scenario you should switch to writing out a script that you
 then include with an INSTALL(SCRIPT command. They are absolutely equivalent,
 except with CODE you specify the code inline when it does not need
 significant escaping, or if it's just a line or two. If it does need lots of
 escaping or is longer than 1-3 lines, I would say it should be the SCRIPT
 form anyway.

 And honestly, I think that Eric's suggestion of using a
 CPACK_PROJECT_CONFIG_FILE is the way to go here. If you have one, CPack will
 include it before running your install rules. You can use any sentinel you
 like within that file: it will only ever be included by CPack, so if you're
 in its context, then you know you're being run by CPack.

That's a good suggestion and could do with being better documented
(like most of CPack)!

I still think the nicest solution would be to provide INSTALL(...
PACKAGE) or something similar so you can do this all easily and
visibly from your existing CMakeLists.txt files. That's my main
reservation with using too many external script files, it's not
obvious to someone reading the CMakeLists file what is actually
happening.

I'm happy to write a patch for this. Would this be accepted? Is this
the wrong approach? If you guide me to creating an acceptable one, I'd
be happy to write this.

I created a bug about this so this is probably a good point of discussion:
http://public.kitware.com/Bug/view.php?id=11142

-- 
Mike McQuaid
http://mikemcquaid.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

[CMake] (Error) Symbian Carbide Generator

[shivaji badade]

Hi,

I am trying to use the Symbian Carbide Generator from 
http://public.kitware.com/Bug/view.php?id=8486#c22281;

I have taken master branch and on top of it patches for symbian genrator
from Assaf at location


https://docs.google.com/uc?id=0BzHCK1hf14h2ZGFkNDE3MmEtNDc5MC00Njg5LTk4ZmItODVhNWFkYjZiMmU0export=downloadhl=en


when I trying to compile the patched Cmake getting following errors

3cmCPackNSISGenerator.cxx
2..\..\Source\cmGlobalCarbideGenerator.cxx(284) : error C2039: 'CreateGUID'
: is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25)
: see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(285) : error C2039: 'CreateGUID'
: is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25)
: see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(286) : error C2039: 'CreateGUID'
: is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25)
: see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(287) : error C2039: 'CreateGUID'
: is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25)
: see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(288) : error C2039: 'CreateGUID'
: is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25)
: see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(289) : error C2039: 'CreateGUID'
: is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25)
: see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(395) : error C2660:
'cmGlobalGenerator::TryCompile' : function does not take 7 arguments

Please let me know anybody faced same issue or anyother tool available
to generate the SYMBIAN project out of OpenSource.

Thanks
Shivaji
1-- Skipped Build: Project: RUN_TESTS, Configuration: Debug Win32 --
1Project not selected to build for this solution configuration 
2-- Build started: Project: CMakeLib, Configuration: Debug Win32 --
3-- Build started: Project: CPackLib, Configuration: Debug Win32 --
3Compiling...
2Compiling...
3cmCPackTarCompressGenerator.cxx
2cmBootstrapCommands.cxx
3cmCPackTarBZip2Generator.cxx
2cmLocalCarbideGenerator.cxx
3cmCPackTGZGenerator.cxx
3cmCPackSTGZGenerator.cxx
2cmGlobalCarbideGenerator.cxx
3cmCPackNSISGenerator.cxx
2..\..\Source\cmGlobalCarbideGenerator.cxx(284) : error C2039: 'CreateGUID' : 
is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : 
see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(285) : error C2039: 'CreateGUID' : 
is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : 
see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(286) : error C2039: 'CreateGUID' : 
is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : 
see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(287) : error C2039: 'CreateGUID' : 
is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : 
see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(288) : error C2039: 'CreateGUID' : 
is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : 
see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(289) : error C2039: 'CreateGUID' : 
is not a member of 'cmGlobalCarbideGenerator'
2
c:\lucene_source\symbiangeneratortool\b\source\cmGlobalCarbideGenerator.h(25) : 
see declaration of 'cmGlobalCarbideGenerator'
2..\..\Source\cmGlobalCarbideGenerator.cxx(395) : error C2660: 
'cmGlobalGenerator::TryCompile' : function does not take 7 arguments
2cmLocalVisualStudioGenerator.cxx
3cmCPackGenerator.cxx
2cmLocalVisualStudio7Generator.cxx
3Generating Code...
3Creating library...
3Build log was saved at 
file://c:\lucene_source\SymbianGeneratorTool\b\OutofSource\Source\CPackLib.dir\Debug\BuildLog.htm
3CPackLib - 0 error(s), 0 warning(s)
4-- Build started: Project: CTestLib, Configuration: Debug Win32 --
4Compiling...
4cmCTest.cxx
2cmLocalVisualStudio6Generator.cxx
2cmGlobalWatcomWMakeGenerator.cxx
4cmCTestUpdateHandler.cxx
2cmGlobalVisualStudioGenerator.cxx

Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?

[David Cole]

On Mon, Dec 20, 2010 at 7:51 AM, Mike McQuaid m...@mikemcquaid.com wrote:

 On 20 December 2010 12:34, David Cole david.c...@kitware.com wrote:
  On Sun, Dec 19, 2010 at 3:50 PM, Mike McQuaid m...@mikemcquaid.com
 wrote:
  When you find yourself in the must escape too much situation in an
  INSTALL(CODE scenario you should switch to writing out a script that
 you
  then include with an INSTALL(SCRIPT command. They are absolutely
 equivalent,
  except with CODE you specify the code inline when it does not need
  significant escaping, or if it's just a line or two. If it does need lots
 of
  escaping or is longer than 1-3 lines, I would say it should be the SCRIPT
  form anyway.
 
  And honestly, I think that Eric's suggestion of using a
  CPACK_PROJECT_CONFIG_FILE is the way to go here. If you have one, CPack
 will
  include it before running your install rules. You can use any sentinel
 you
  like within that file: it will only ever be included by CPack, so if
 you're
  in its context, then you know you're being run by CPack.

 That's a good suggestion and could do with being better documented
 (like most of CPack)!

 I still think the nicest solution would be to provide INSTALL(...
 PACKAGE) or something similar so you can do this all easily and
 visibly from your existing CMakeLists.txt files. That's my main
 reservation with using too many external script files, it's not
 obvious to someone reading the CMakeLists file what is actually
 happening.

 I'm happy to write a patch for this. Would this be accepted? Is this
 the wrong approach? If you guide me to creating an acceptable one, I'd
 be happy to write this.

 I created a bug about this so this is probably a good point of discussion:
 http://public.kitware.com/Bug/view.php?id=11142

 --
 Mike McQuaid
 http://mikemcquaid.com



I don't think an INSTALL(... PACKAGE construct is necessary. And, in fact, I
think it might be harmful. (For one thing, INSTALL(PACKAGE sounds like
you're installing a package, not like you're installing something you've
built but only as part of an installer package.)

For the simple case, the binary package is nothing more than a copy of the
make install tree. Adding stuff to the tree, but only for package
installers, is unusual. But it is possible with existing mechanisms. (I
still wouldn't recommend doing it.)

Why do you have differences in one install tree vs. another?
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?

[Mike McQuaid]

On 20 December 2010 13:17, David Cole david.c...@kitware.com wrote:
 I don't think an INSTALL(... PACKAGE construct is necessary. And, in fact, I
 think it might be harmful. (For one thing, INSTALL(PACKAGE sounds like
 you're installing a package, not like you're installing something you've
 built but only as part of an installer package.)

Ok. I'm not saying that's the best keyword or anything like that but
just something that handles the escaping for you but lets you specify
files within CMake.

 For the simple case, the binary package is nothing more than a copy of the
 make install tree. Adding stuff to the tree, but only for package
 installers, is unusual. But it is possible with existing mechanisms. (I
 still wouldn't recommend doing it.)

 Why do you have differences in one install tree vs. another?

Anyone who uses GetPrerequisites or BundleUtilities will do. I've had
this problem now on 5+ projects between 2+ employers. You will want to
install the libraries for your application to a package you can
distribute but not to people on e.g. Linux who just want to type make
install and had it use their system libraries.

Another case is adding things like the README which should be in the
root of the zip/dmg package but in  $PREFIX/share/doc for
installations. Also, you might want to fix up RPATHS for installed
versions but not local ones. You'll also need to supply a qt.conf file
for Qt installations at package-time but not install-time.

Any open-source project where you want to provide binary package
support using CMake but allow people to create normal Linux/Mac
packages themselves (e.g. Debian) will require a different
install/package tree. In my experience, literally every time I've used
CPack for a project or recommended it to others they've required this
functionality. That's not to say that it is used in every single
project using CPack out there but it seems to be necessary to a lot of
users.

-- 
Mike McQuaid
http://mikemcquaid.com
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Macro for adding cflags, odd quirk with CHECK_C_COMPILER_FLAG

[Brad King]

On 12/16/2010 01:07 PM, Campbell Barton wrote:
 My question is why this is needed?
   set(CFLAG_TEST CFLAG_TEST)
   CHECK_C_COMPILER_FLAG(${_FLAG} CFLAG_TEST)

The CHECK_C_COMPILER_FLAG macro stores its result in the CMake cache so
that it persists across multiple runs in the same build tree.  Otherwise
it will run the check every time which is far too expensive.  Every call
to this macro should have a unique name as the second argument to store
the result persistently.

 MACRO(CHECK_C_SOURCE_COMPILES SOURCE VAR)
   IF(${VAR} MATCHES ^${VAR}$)

This is check is a hack for

  if(NOT DEFINED ${VAR})

from before the DEFINED test was supported by CMake's if() command.
Some uses of the old hack are still floating around.  Note that the
purpose is to test if the variable named by ${VAR} is defined, not
whether the variable VAR itself is defined.

-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

[CMake] Setting up command line arguments on generated executables

[Alessandro Carpi]

Hi there,

I am using cmake to generate Xcode projects starting from the usual
CMakeLists.txt

I often modify CMakeLists.txt to add some source, so I have to re-generate
the whole project using cmake path -G Xcode, but everytime I have to
manually set up the executable command line arguments from Xcode.

Is there a declaration to add in the CMakeLists.txt in order to generate a
project that has executables arguments already defined ?

Thank you very much,

--
Alessandro Carpi
___
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] Setting up command line arguments on generated executables

[Michael Wild]

On 12/20/2010 03:34 PM, Alessandro Carpi wrote:
 Hi there,
 
 I am using cmake to generate Xcode projects starting from the usual
 CMakeLists.txt
 
 I often modify CMakeLists.txt to add some source, so I have to re-generate
 the whole project using cmake path -G Xcode, but everytime I have to
 manually set up the executable command line arguments from Xcode.
 
 Is there a declaration to add in the CMakeLists.txt in order to generate a
 project that has executables arguments already defined ?
 
 Thank you very much,
 
 --
 Alessandro Carpi


CMake re-runs itself if you modify the CMakeLists.txt files. Just hit
the build button...

Michael

___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to detect whether CMake scripts are executing under / within CPack environment?

[Mike McQuaid]

On 20 December 2010 16:07, Clinton Stimpson clin...@elemtech.com wrote:
 BundleUtilities already skips system libraries, so I don't see a difference
 between making a package and make install in this case.
 If you're using all system libraries, BundleUtilities can become a no-op.

You're basically saying don't use BundleUtilities and CPack to create
binary packages for open-source projects. On Mac or Windows I want to
be able to distribute to users using both package managers and binary
packages (e.g. CPack installers). The prior handles dependencies for
you so you don't want to install anything not built by the project.
The latter requires you to bundle all dependencies not distributed
with a default install of the system.

I don't mind if BundleUtilities is run or not, just that the libraries
aren't installed with make install and are installed with make
package.


 Another case is adding things like the README which should be in the
 root of the zip/dmg package but in  $PREFIX/share/doc for
 installations.

 Then you'll have to differentiate between cpack generators.  You might want
 that for zip and dmg, but not for rpm and deb.

Yes, you might. Also, you might just not use those generators.


 Why would this matter?  If you're using system libraries, rpaths are not
 needed and ld.so.conf does the work for you.
 When a package is made, you want absolute rpaths removed anyway, since they
 may not work on other systems.

It might not matter to you, it's just another example of concerns
people have in the open-source world.


 You'll also need to supply a qt.conf file
 for Qt installations at package-time but not install-time.

 I think, whether to make qt.conf and add Qt plugins is really dependent on
 whether the Qt libraries will get copied by BundleUtilities, not whether
 you're doing a make install vs. a make package.

Qt plugins won't be installed by BundleUtilities as far as I can see.
In this case, you're somewhat mixing together BundleUtilities and
CPack. I've never seen any use for BundleUtilities on any of the
projects I've worked on either commercially or in open-source work for
anything other than generating packages that are distributed to users.
This is packaging as far as I can see, not installation.


 Any open-source project where you want to provide binary package
 support using CMake but allow people to create normal Linux/Mac
 packages themselves (e.g. Debian) will require a different
 install/package tree. In my experience, literally every time I've used
 CPack for a project or recommended it to others they've required this
 functionality. That's not to say that it is used in every single
 project using CPack out there but it seems to be necessary to a lot of
 users.

 BundleUtilities still works in this case but can basically become a no-op.

I don't mind whether BundleUtilities works or not.

This discussion is about CPack and CMake's interaction, not really
about BundleUtilities. I'm trying really hard to be an advocate of
CPack, I've done internal company presentations at several companies,
I plug it when I do Qt trainings and did a talk and workshop at the
KDE conference before last at it. At my current company (KDAB) we're
trying to use CPack for several internal products and an open-source
tool. Personally, I'm trying to use it for some open-source projects
and producing decent Mac KDE binary packages.

This is a problem that I keep running into again and again and
currently there isn't a nice solution. When I show people
INSTALL(CODE) blocks or external scripts required for the above, they
go oh and I can see their desire to use CPack decreases. I'm happy
to try and fix this but please don't tell me this isn't a problem.

-- 
Mike McQuaid
http://mikemcquaid.com
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Setting up command line arguments on generated executables

[Ryan Pavlik]

The issue here is that XCode stores those command line arguments into the
same project file that CMake re-generates. I'm pretty sure there's an open
bug on this one, but it's a somewhat tricky issue.  You might consider using
my CreateLaunchers cmake modules, available here [1] - while they don't
directly handle the xcode issue (though they handle Visual Studio, which has
a similar issue but uses separate files), they do generate launch scripts on
all platforms that you can use, and allow you to specify the command line
arguments in the build files.

Hope this helps!

Ryan

[1]https://github.com/rpavlik/cmake-modules

On Mon, Dec 20, 2010 at 8:47 AM, Michael Wild them...@gmail.com wrote:

 On 12/20/2010 03:34 PM, Alessandro Carpi wrote:
  Hi there,
 
  I am using cmake to generate Xcode projects starting from the usual
  CMakeLists.txt
 
  I often modify CMakeLists.txt to add some source, so I have to
 re-generate
  the whole project using cmake path -G Xcode, but everytime I have to
  manually set up the executable command line arguments from Xcode.
 
  Is there a declaration to add in the CMakeLists.txt in order to generate
 a
  project that has executables arguments already defined ?
 
  Thank you very much,
 
  --
  Alessandro Carpi


 CMake re-runs itself if you modify the CMakeLists.txt files. Just hit
 the build button...

 Michael

 ___
 Powered by www.kitware.com

 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/listinfo/cmake




-- 
Ryan Pavlik
HCI Graduate Student
Virtual Reality Applications Center
Iowa State University

rpav...@iastate.edu
http://academic.cleardefinition.com
Internal VRAC/HCI Site: http://tinyurl.com/rpavlik
___
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] can't build translated makefile on snow leopard 10.6.5 w/ g++ 4.2.1 (complaint: g++: No such file or directory, although g++ is there!!)

[ny]

 greetings!

I am trying to build research code written in (templated) c++, size
is approximately ~15K lines.

The code was never been tested on a mac, not to mention snow leopard.
I have the guarantee that it compiles + builds for win + linux.
Project was a collaborative effort and unfortunately I am stuck without a
makefile =P and with the ugly *.vcproj file. Note that I did not use an
automated  ruby script I found for
the translation of *.vcproj to makefile, since the script only
handled the basics - no pre/post-build steps or file-specific flags are
included;
instead, I translated from scratch to CMakelists and then converted to
makefile. not that tricky as it sounds..

So, assuming the problem is w/ the makefile, why do I have a clean
makefile during the configuration/generation steps?
Note that I choose to generate Unix makefile, not an xcode project.

I 've successfully translated the *.vcproj file into a makefile,
fixed a few issues, linked to external libs, but the build w/ make fails and
I get

*i686-apple-darwin10-g++-4.2.1: g++: No such file or directory
make[2]: *** [CMakeFiles/.../.../...cpp.o] Error 1
make[1]: *** [CMakeFiles/.../.../all] Error 2
make: *** [all] Error 2
*
which, honestly, I don't remember seeing before - complaining about
g++ I mean and not missing file or dir. Note that g++ *is* in place, I can
successfully compile other programs.

Assuming that /usr/bin was somehow not in the path during the cmake
invocation,
I used
*
*
*set(CMAKE_C_COMPILER /usr/bin/gcc)*
*set(CMAKE_CXX_COMPILER /usr/bin/g++)*

in the beginning of my CMakeList.txt without any luck.
It complained temporarily for a conflict, i.e. had to reset the cache,
but no progress so far. I


I am stuck a few hours now and I suspect  (or better hope) that the
problem is sth similar to the typical 32-bit/64-bit problem in mac
ports. I tried w/ -arch i386 -m32  flags without any luck, so I 'd love to
hear any thoughts, ideas..
I guess there are parts of the code need to be re-written especially
for OS X SL, but I cannot figure out the problem since the failing error is
not
descriptive enough.

When I build a xcodeproj (with g++ flag -arch i386), I get:

*lipo: can't figure out the architecture type of: /var/folders/9b/
9b2CWG5gHvCi5hawjO4o5E+++TI/-Tmp-//ccXHDX6t.out
Command /Developer/usr/bin/gcc-4.2 failed with exit code 1
*
When I build a xcodeproj (with g++ flag -arch x86_64), I get:

*setenv LANG en_US.US-ASCII
/Developer/usr/bin/gcc-4.2 -x c++ -arch x86_64 -fmessage-length=0 -
pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -mdynamic-no-
pic -DCMAKE_INTDIR=Debug -isysroot /Developer/SDKs/MacOSX10.6.sdk -
mmacosx-version-min=10.6 -gdwarf-2 -Wmost -Wno-four-char-constants -
Wno-unknown-pragmas //... ...
i686-apple-darwin10-gcc-4.2.1: g++: No such file or directory
Command /Developer/usr/bin/gcc-4.2 failed with exit code 1*

all cryptic..

Finally, although developing on a mac, I do not use Cocoa(/xcode)
that uses otool to find any required shared libraries. So from the
command line I don't have to care about otool and instead I use the ldd.

thanks for any help!

ps. note that I am building from command line without xcode
and the -pedantic flag I use is not the reason of the failure
___
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] can't build translated makefile on snow leopard 10.6.5 w/ g++ 4.2.1 (complaint: g++: No such file or directory, although g++ is there!!)

[Andreas Pakulat]

On 20.12.10 23:34:55, ny wrote:
 The code was never been tested on a mac, not to mention snow leopard.
 I have the guarantee that it compiles + builds for win + linux.
 Project was a collaborative effort and unfortunately I am stuck without a
 makefile =P and with the ugly *.vcproj file. Note that I did not use an
 automated  ruby script I found for

Then either it doesn't build on Linux or there must be something else
for Linux. There is no buildsystem that operates on .vcproj files
(afaik) except VS which doesn't work on Linux.

 the translation of *.vcproj to makefile, since the script only
 handled the basics - no pre/post-build steps or file-specific flags are
 included;
 instead, I translated from scratch to CMakelists and then converted to
 makefile. not that tricky as it sounds..
 
 So, assuming the problem is w/ the makefile, why do I have a clean
 makefile during the configuration/generation steps?

Are you mixing up Makefile (which is something that make works with) and
CMakeLists.txt (which is the input for cmake, which then generates
Makefiles from it)? To me the above doesn't make much sense when talking
purely about Makefile's.

 Note that I choose to generate Unix makefile, not an xcode project.
 
 I 've successfully translated the *.vcproj file into a makefile,
 fixed a few issues, linked to external libs, but the build w/ make fails and
 I get
 
 *i686-apple-darwin10-g++-4.2.1: g++: No such file or directory
 make[2]: *** [CMakeFiles/.../.../...cpp.o] Error 1
 make[1]: *** [CMakeFiles/.../.../all] Error 2
 make: *** [all] Error 2
 *

Whats the full errror and the full compile line (run make VERBOSE=1)?

 which, honestly, I don't remember seeing before - complaining about
 g++ I mean and not missing file or dir. Note that g++ *is* in place, I can
 successfully compile other programs.

 Assuming that /usr/bin was somehow not in the path during the cmake
 invocation,
 I used
 *
 *
 *set(CMAKE_C_COMPILER /usr/bin/gcc)*
 *set(CMAKE_CXX_COMPILER /usr/bin/g++)*
 
 in the beginning of my CMakeList.txt without any luck.
 It complained temporarily for a conflict, i.e. had to reset the cache,
 but no progress so far. I
 
 
 I am stuck a few hours now and I suspect  (or better hope) that the
 problem is sth similar to the typical 32-bit/64-bit problem in mac
 ports. I tried w/ -arch i386 -m32  flags without any luck, so I 'd love to
 hear any thoughts, ideas..
 I guess there are parts of the code need to be re-written especially
 for OS X SL, but I cannot figure out the problem since the failing error is
 not
 descriptive enough.
 
 When I build a xcodeproj (with g++ flag -arch i386), I get:
 
 *lipo: can't figure out the architecture type of: /var/folders/9b/
 9b2CWG5gHvCi5hawjO4o5E+++TI/-Tmp-//ccXHDX6t.out
 Command /Developer/usr/bin/gcc-4.2 failed with exit code 1
 *
 When I build a xcodeproj (with g++ flag -arch x86_64), I get:
 
 *setenv LANG en_US.US-ASCII
 /Developer/usr/bin/gcc-4.2 -x c++ -arch x86_64 -fmessage-length=0 -
 pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -mdynamic-no-
 pic -DCMAKE_INTDIR=Debug -isysroot /Developer/SDKs/MacOSX10.6.sdk -
 mmacosx-version-min=10.6 -gdwarf-2 -Wmost -Wno-four-char-constants -
 Wno-unknown-pragmas //... ...
 i686-apple-darwin10-gcc-4.2.1: g++: No such file or directory
 Command /Developer/usr/bin/gcc-4.2 failed with exit code 1*
 
 all cryptic..

Do you have a g++ in /Developer/usr/bin/? I don't know too much about
the setup of Compilers on MacOSX, but if gcc-4.2 is run in that path,
maybe it expects the g++ at the same place and not just /usr/bin (unless
the two are symlinked).

Andreas

-- 
Tonight's the night: Sleep in a eucalyptus tree.
___
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] can't build translated makefile on snow leopard 10.6.5 w/ g++ 4.2.1 (complaint: g++: No such file or directory, although g++ is there!!)

[Ryan Pavlik]

It seems you might be over-analyzing the conversion: makefiles are much
lower-level than well-written cmake build systems.  I would suggest you
start with the CMake tutorial [1], then start from scratch on the build
system for this code.  Think at a high level, about what files turn into
what executables and libraries - my experience has been that the most
time-consuming task of creating a cmake-based build system is creating the
modules to find dependencies, not the actual creation of the basic build
itself.  ls *.cpp *.h | sort | pbcopy is a handy command on the mac - you
can then just paste and have a list of the c++ source files from a
directory.  (I'll stop you ahead of time: don't use file(GLOB) - it is not
the right solution.)  Also, don't put anything in your cmakelists.txt files
that is system-specific: the purpose of these files is to handle configuring
and building on a number of different machines, with the idea that the
user/developer configures the system-specific settings in the cmake gui.

If you do this and still have issues, we'll need to see more of the build
system files (cmakelists.txt files) to be able to help.

Ryan

[1] http://www.cmake.org/cmake/help/cmake_tutorial.html

On Mon, Dec 20, 2010 at 4:34 PM, ny nikos.yio...@gmail.com wrote:

 greetings!

 I am trying to build research code written in (templated) c++, size
 is approximately ~15K lines.

 The code was never been tested on a mac, not to mention snow leopard.
 I have the guarantee that it compiles + builds for win + linux.
 Project was a collaborative effort and unfortunately I am stuck without a
 makefile =P and with the ugly *.vcproj file. Note that I did not use an
 automated  ruby script I found for
 the translation of *.vcproj to makefile, since the script only
 handled the basics - no pre/post-build steps or file-specific flags are
 included;
 instead, I translated from scratch to CMakelists and then converted to
 makefile. not that tricky as it sounds..

 So, assuming the problem is w/ the makefile, why do I have a clean
 makefile during the configuration/generation steps?
 Note that I choose to generate Unix makefile, not an xcode project.

 I 've successfully translated the *.vcproj file into a makefile,
 fixed a few issues, linked to external libs, but the build w/ make fails
 and
 I get

 *i686-apple-darwin10-g++-4.2.1: g++: No such file or directory
 make[2]: *** [CMakeFiles/.../.../...cpp.o] Error 1
 make[1]: *** [CMakeFiles/.../.../all] Error 2
 make: *** [all] Error 2
 *
 which, honestly, I don't remember seeing before - complaining about
 g++ I mean and not missing file or dir. Note that g++ *is* in place, I can
 successfully compile other programs.

 Assuming that /usr/bin was somehow not in the path during the cmake
 invocation,
 I used
 *
 *
 *set(CMAKE_C_COMPILER /usr/bin/gcc)*
 *set(CMAKE_CXX_COMPILER /usr/bin/g++)*

 in the beginning of my CMakeList.txt without any luck.
 It complained temporarily for a conflict, i.e. had to reset the cache,
 but no progress so far. I


 I am stuck a few hours now and I suspect  (or better hope) that the
 problem is sth similar to the typical 32-bit/64-bit problem in mac
 ports. I tried w/ -arch i386 -m32  flags without any luck, so I 'd love to
 hear any thoughts, ideas..
 I guess there are parts of the code need to be re-written especially
 for OS X SL, but I cannot figure out the problem since the failing error is
 not
 descriptive enough.

 When I build a xcodeproj (with g++ flag -arch i386), I get:

 *lipo: can't figure out the architecture type of: /var/folders/9b/
 9b2CWG5gHvCi5hawjO4o5E+++TI/-Tmp-//ccXHDX6t.out
 Command /Developer/usr/bin/gcc-4.2 failed with exit code 1
 *
 When I build a xcodeproj (with g++ flag -arch x86_64), I get:

 *setenv LANG en_US.US-ASCII
 /Developer/usr/bin/gcc-4.2 -x c++ -arch x86_64 -fmessage-length=0 -
 pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -mdynamic-no-
 pic -DCMAKE_INTDIR=Debug -isysroot /Developer/SDKs/MacOSX10.6.sdk -
 mmacosx-version-min=10.6 -gdwarf-2 -Wmost -Wno-four-char-constants -
 Wno-unknown-pragmas //... ...
 i686-apple-darwin10-gcc-4.2.1: g++: No such file or directory
 Command /Developer/usr/bin/gcc-4.2 failed with exit code 1*

 all cryptic..

 Finally, although developing on a mac, I do not use Cocoa(/xcode)
 that uses otool to find any required shared libraries. So from the
 command line I don't have to care about otool and instead I use the ldd.

 thanks for any help!

 ps. note that I am building from command line without xcode
 and the -pedantic flag I use is not the reason of the failure


 ___
 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




-- 
Ryan Pavlik
HCI Graduate Student
Virtual 

[CMake] Maintainer for FindX11, FindOpenGL, and FindTCL (and friends)

[Clifford Yapp]

Looking at http://www.cmake.org/Wiki/CMake:Module_Maintainers (thanks
Brad for the link) it looks like my best option may be to actually
volunteer for the maintainership of FindX11, FindOpenGL and
FindTCL(sh/stubs/etc...), as they are not listed as being actively
maintained.

Since I need these modules in any case and would have to keep them
working for my own purposes, this would seem to be a workable
solution.  I had hesitated to propose this step because I had figured
Kitware would prefer to itself maintain the Find modules for such
central functionality, but if they are indeed on the list of modules
for whom a maintainer candidate is sought I'm willing to give it a go.

FindX11.cmake and FindOpenGL.cmake are fairly straightforward, but in
the case of Tcl/Tk I would prefer to move back from the splitting up
of Tcl/Tk functionality to just FindTCL.cmake - the primary reason for
this is to avoid situations where there are multiple Tcl/Tk systems
installed and the tclsh search returns a tclsh executable that is not
the tclsh associated with the libraries of the Tcl selected by the
find_library logic.  It might be conceivable to put some constraint
logic in to make a find_package on one to conform to the results
already found by another, but that seems awfully forced.  By the same
token, there is no reason the tclsh and tclstub find files need to
march to the same drummer as the FindTCL.cmake file, although the
results might be somewhat surprising if they didn't.

Tcl/Tk appears to have been a significant focus of the original
developers.  I'm leery about becoming maintainer and making such
radical changes to something the Kitware devs probably need without
approval, so I'd like to discuss it here (unless it's just flat out
unworkable, of course ;-)

Cheers,
CY
___
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] can't build translated makefile on snow leopard 10.6.5 w/ g++ 4.2.1 (complaint: g++: No such file or directory, although g++ is there!!)

[ny]

On Mon, Dec 20, 2010 at 11:54 PM, Ryan Pavlik rpav...@iastate.edu wrote:

 It seems you might be over-analyzing the conversion: makefiles are much
 lower-level than well-written cmake build systems.  I would suggest you
 start with the CMake tutorial [1], then start from scratch on the build
 system for this code.  Think at a high level, about what files turn into
 what executables and libraries - my experience has been that the most
 time-consuming task of creating a cmake-based build system is creating the
 modules to find dependencies, not the actual creation of the basic build
 itself.  ls *.cpp *.h | sort | pbcopy is a handy command on the mac - you
 can then just paste and have a list of the c++ source files from a
 directory.  (I'll stop you ahead of time: don't use file(GLOB) - it is not
 the right solution.)  Also, don't put anything in your cmakelists.txt files
 that is system-specific: the purpose of these files is to handle configuring
 and building on a number of different machines, with the idea that the
 user/developer configures the system-specific settings in the cmake gui.

 If you do this and still have issues, we'll need to see more of the build
 system files (cmakelists.txt files) to be able to help.

 Ryan


thanks. as for now I from experimenting w/

[1] http://www.cmake.org/cmake/help/cmake_tutorial.html

the culprit was the line *CPPFLAGS   = -g -c -Wall -arch i386*
left inside CMakeLists.txt, (more relevant to a makefile).
It still does not compile, there is a linking issue,
but I am not far from a 4/4 (parts) compilation. will check it 'n
let you know

On Mon, Dec 20, 2010 at 4:34 PM, ny nikos.yio...@gmail.com wrote:

  greetings!

 I am trying to build research code written in (templated) c++, size
 is approximately ~15K lines.

 The code was never been tested on a mac, not to mention snow leopard.
 I have the guarantee that it compiles + builds for win + linux.
 Project was a collaborative effort and unfortunately I am stuck without a
 makefile =P and with the ugly *.vcproj file. Note that I did not use an
 automated  ruby script I found for
 the translation of *.vcproj to makefile, since the script only
 handled the basics - no pre/post-build steps or file-specific flags are
 included;
 instead, I translated from scratch to CMakelists and then converted to
 makefile. not that tricky as it sounds..

 So, assuming the problem is w/ the makefile, why do I have a clean
 makefile during the configuration/generation steps?
 Note that I choose to generate Unix makefile, not an xcode project.

 I 've successfully translated the *.vcproj file into a makefile,
 fixed a few issues, linked to external libs, but the build w/ make fails
 and
 I get

 *i686-apple-darwin10-g++-4.2.1: g++: No such file or directory
 make[2]: *** [CMakeFiles/.../.../...cpp.o] Error 1
 make[1]: *** [CMakeFiles/.../.../all] Error 2
 make: *** [all] Error 2
 *
 which, honestly, I don't remember seeing before - complaining about
 g++ I mean and not missing file or dir. Note that g++ *is* in place, I can
 successfully compile other programs.

 Assuming that /usr/bin was somehow not in the path during the cmake
 invocation,
 I used
 *
 *
 *set(CMAKE_C_COMPILER /usr/bin/gcc)*
 *set(CMAKE_CXX_COMPILER /usr/bin/g++)*

 in the beginning of my CMakeList.txt without any luck.
 It complained temporarily for a conflict, i.e. had to reset the cache,
 but no progress so far. I


 I am stuck a few hours now and I suspect  (or better hope) that the
 problem is sth similar to the typical 32-bit/64-bit problem in mac
 ports. I tried w/ -arch i386 -m32  flags without any luck, so I 'd love
 to
 hear any thoughts, ideas..
 I guess there are parts of the code need to be re-written especially
 for OS X SL, but I cannot figure out the problem since the failing error
 is not
 descriptive enough.

 When I build a xcodeproj (with g++ flag -arch i386), I get:

 *lipo: can't figure out the architecture type of: /var/folders/9b/
 9b2CWG5gHvCi5hawjO4o5E+++TI/-Tmp-//ccXHDX6t.out
 Command /Developer/usr/bin/gcc-4.2 failed with exit code 1
 *
 When I build a xcodeproj (with g++ flag -arch x86_64), I get:

 *setenv LANG en_US.US-ASCII
 /Developer/usr/bin/gcc-4.2 -x c++ -arch x86_64 -fmessage-length=0 -
 pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -mdynamic-no-
 pic -DCMAKE_INTDIR=Debug -isysroot /Developer/SDKs/MacOSX10.6.sdk -
 mmacosx-version-min=10.6 -gdwarf-2 -Wmost -Wno-four-char-constants -
 Wno-unknown-pragmas //... ...
 i686-apple-darwin10-gcc-4.2.1: g++: No such file or directory
 Command /Developer/usr/bin/gcc-4.2 failed with exit code 1*

 all cryptic..

 Finally, although developing on a mac, I do not use Cocoa(/xcode)
 that uses otool to find any required shared libraries. So from the
 command line I don't have to care about otool and instead I use the ldd.

 thanks for any help!

 ps. note that I am building from command line without xcode
 and the -pedantic flag I use is not the reason of the failure


 

[CMake] copy_resolved_item_into_bundle doesn't copy when I want it to

[Ben Medina]

Hello all,

I'm using fixup_bundle as part of my installation rules. One problem
I've run into is that if you build the install target multiple times,
fixup_bundle (or, more specifically, copy_resolved_item_into_bundle)
won't copy a library over if it's coming from the same location. This
causes a failure for the following workflow:

1. Build the install target.
2. Make a change to one of the libraries that fixup_bundle resolved for you.
3. Build the install target again.

The second time you build the install, the updated library does not
get copied, and any application that depends on the change in that
library will be broken.

Is there is reason copy_resolved_item_into_bundle doesn't just use
copy_if_different?

Thanks,
Ben
___
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] can't build translated makefile on snow leopard 10.6.5 w/ g++ 4.2.1 (complaint: g++: No such file or directory, although g++ is there!!)

[ny]

On Mon, Dec 20, 2010 at 11:53 PM, Andreas Pakulat ap...@gmx.de wrote:

 On 20.12.10 23:34:55, ny wrote:
  The code was never been tested on a mac, not to mention snow leopard.
  I have the guarantee that it compiles + builds for win + linux.
  Project was a collaborative effort and unfortunately I am stuck without a
  makefile =P and with the ugly *.vcproj file. Note that I did not use an
  automated  ruby script I found for

 Then either it doesn't build on Linux or there must be something else
 for Linux. There is no buildsystem that operates on .vcproj files
 (afaik) except VS which doesn't work on Linux.


 I have the guarantee that it compiles + builds for linux, not the makefile
though =P


  the translation of *.vcproj to makefile, since the script only
  handled the basics - no pre/post-build steps or file-specific flags are
  included;
  instead, I translated from scratch to CMakelists and then converted to
  makefile. not that tricky as it sounds..
 
  So, assuming the problem is w/ the makefile, why do I have a clean
  makefile during the configuration/generation steps?

 Are you mixing up Makefile (which is something that make works with) and
 CMakeLists.txt (which is the input for cmake, which then generates
 Makefiles from it)? To me the above doesn't make much sense when talking
 purely about Makefile's.


indeed, the ruby script was translating *.vcproj to CMakelists *not* to
makefile.
thanks


  Note that I choose to generate Unix makefile, not an xcode project.
 
  I 've successfully translated the *.vcproj file into a makefile,
  fixed a few issues, linked to external libs, but the build w/ make fails
 and
  I get
 
  *i686-apple-darwin10-g++-4.2.1: g++: No such file or directory
  make[2]: *** [CMakeFiles/.../.../...cpp.o] Error 1
  make[1]: *** [CMakeFiles/.../.../all] Error 2
  make: *** [all] Error 2
  *

 Whats the full errror and the full compile line (run make VERBOSE=1)?

  which, honestly, I don't remember seeing before - complaining about
  g++ I mean and not missing file or dir. Note that g++ *is* in place, I
 can
  successfully compile other programs.
 
  Assuming that /usr/bin was somehow not in the path during the cmake
  invocation,
  I used
  *
  *
  *set(CMAKE_C_COMPILER /usr/bin/gcc)*
  *set(CMAKE_CXX_COMPILER /usr/bin/g++)*
 
  in the beginning of my CMakeList.txt without any luck.
  It complained temporarily for a conflict, i.e. had to reset the cache,
  but no progress so far. I
 
 
  I am stuck a few hours now and I suspect  (or better hope) that the
  problem is sth similar to the typical 32-bit/64-bit problem in mac
  ports. I tried w/ -arch i386 -m32  flags without any luck, so I 'd love
 to
  hear any thoughts, ideas..
  I guess there are parts of the code need to be re-written especially
  for OS X SL, but I cannot figure out the problem since the failing error
 is
  not
  descriptive enough.
 
  When I build a xcodeproj (with g++ flag -arch i386), I get:
 
  *lipo: can't figure out the architecture type of: /var/folders/9b/
  9b2CWG5gHvCi5hawjO4o5E+++TI/-Tmp-//ccXHDX6t.out
  Command /Developer/usr/bin/gcc-4.2 failed with exit code 1
  *
  When I build a xcodeproj (with g++ flag -arch x86_64), I get:
 
  *setenv LANG en_US.US-ASCII
  /Developer/usr/bin/gcc-4.2 -x c++ -arch x86_64 -fmessage-length=0 -
  pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -mdynamic-no-
  pic -DCMAKE_INTDIR=Debug -isysroot /Developer/SDKs/MacOSX10.6.sdk -
  mmacosx-version-min=10.6 -gdwarf-2 -Wmost -Wno-four-char-constants -
  Wno-unknown-pragmas //... ...
  i686-apple-darwin10-gcc-4.2.1: g++: No such file or directory
  Command /Developer/usr/bin/gcc-4.2 failed with exit code 1*
 
  all cryptic..

 Do you have a g++ in /Developer/usr/bin/? I don't know too much about
 the setup of Compilers on MacOSX, but if gcc-4.2 is run in that path,
 maybe it expects the g++ at the same place and not just /usr/bin (unless
 the two are symlinked).

 Andreas

 --
 Tonight's the night: Sleep in a eucalyptus tree.
 ___
 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] Maintainer for FindX11, FindOpenGL, and FindTCL (and friends)

[Alan W. Irwin]

On 2010-12-20 18:27-0500 Clifford Yapp wrote:


[In] the case of Tcl/Tk I would prefer to move back from the splitting up
of Tcl/Tk functionality to just FindTCL.cmake - the primary reason for
this is to avoid situations where there are multiple Tcl/Tk systems
installed and the tclsh search returns a tclsh executable that is not
the tclsh associated with the libraries of the Tcl selected by the
find_library logic.  It might be conceivable to put some constraint
logic in to make a find_package on one to conform to the results
already found by another, but that seems awfully forced.  By the same
token, there is no reason the tclsh and tclstub find files need to
march to the same drummer as the FindTCL.cmake file, although the
results might be somewhat surprising if they didn't.


I am interested in your post from the perspective of a long-time
Tcl and Tk find module user.

I agree that finding Tcl extensions such as Tk that are consistent
with the version of Tcl that is found is important.  We have run
across this issue with the CMake-based PLplot build system and would
welcome a solution.

I agree that the approach of using a giant Tcl + extensions find
module rather than separated find modules might be preferred because
it would keep all the version consistency enforcement logic contained
in one place, and there might be a good chance (see below) to keep the
cmake code compact by looping through the various extensions. Of
course, if you take that giant find module approach you will want to
give the user the chance to select which Tcl extensions (if any) he
wants to find, but so long as that extension selection functionality
is part of it, I can see no other objections to a giant find module
approach for Tcl and its extensions.

I would also advise writing the giant find module in a way that makes
it easy to add new find capability for extensions since such
extensions continue to be added to Tcl from time to time.  Ideally,
there would be a list of Tcl extensions and associated data that you
loop through to do all the standard find stuff for each extension so
that adding find capability of another Tcl extension would normally
require just adding another component name and associated data to the
extensions list. (I am thinking along the lines of a loop paradigm we
use a lot in the PLplot build system where the loop list consists of
elements which are themselves colon-separated to allow easy parsing of
all required data inside the loop, but you may have your own loop
paradigm you prefer to use instead.)

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Maintainer for FindX11, FindOpenGL, and FindTCL (and friends)

[Clifford Yapp]

On Mon, Dec 20, 2010 at 8:23 PM, Alan W. Irwin
ir...@beluga.phys.uvic.ca wrote:

 I agree that finding Tcl extensions such as Tk that are consistent
 with the version of Tcl that is found is important.  We have run
 across this issue with the CMake-based PLplot build system and would
 welcome a solution.

So far I have been using a combination of sanity checks on found
results and parsing of the sh config files in the Tcl/Tk
installations, which I understand are intended to supply critical
information to the TEA build system.  Fortunately, they are simple
enough that with the help of a clever break-up-into-lines approach
CMake's regex abilities can make sense of the key entries.

 I agree that the approach of using a giant Tcl + extensions find
 module rather than separated find modules might be preferred because
 it would keep all the version consistency enforcement logic contained
 in one place, and there might be a good chance (see below) to keep the
 cmake code compact by looping through the various extensions. Of
 course, if you take that giant find module approach you will want to
 give the user the chance to select which Tcl extensions (if any) he
 wants to find, but so long as that extension selection functionality
 is part of it, I can see no other objections to a giant find module
 approach for Tcl and its extensions.

We might want to distinguish between extensions like Itcl/Itk and
core features like threading support or Aqua vs. X11 windowing
system.  Generally speaking, I've been including in my local
FindTCL.cmake one option per item for things that are a basic for
rejecting a Tcl/Tk installation outright (no threads, Tk is Aqua when
I need X11, version of Tcl is too old, etc.)

For packages that can (in principle) be compiled as additions to an
installed Tcl/Tk (tkhtml, tktable, etc.) I've written a routine that
generates a tcl script designed to capture the version of a package
installed and output it to a file.  For any packages of interest, I
first find my Tcl installation and then run the FIND_TCL_PACKAGE macro
for whatever packages I desire.  Admittedly this is of little use if
you want to use this as a basis to outright reject a Tcl installation,
but it should be possible to integrate your suggestion of supplying a
list of requirements over which to iterate.  I hadn't considered this
because our approach is to build a local copy of the extension if we
can't find it, but that's not always a workable/good approach.

A concern there might be how to handle version number requirements for
the list of packages - it would be fairly simple to specify a list of
packages to check for but supplying candidate version numbers gets a
bit harder - maybe package;version and use a regex to check for the
presence of a ; before processing?

 I would also advise writing the giant find module in a way that makes
 it easy to add new find capability for extensions since such
 extensions continue to be added to Tcl from time to time.  Ideally,
 there would be a list of Tcl extensions and associated data that you
 loop through to do all the standard find stuff for each extension so
 that adding find capability of another Tcl extension would normally
 require just adding another component name and associated data to the
 extensions list. (I am thinking along the lines of a loop paradigm we
 use a lot in the PLplot build system where the loop list consists of
 elements which are themselves colon-separated to allow easy parsing of
 all required data inside the loop, but you may have your own loop
 paradigm you prefer to use instead.)

I think we're thinking along similar lines.  I need to rework my file
a bit anyway to make sure I'm conforming as much as possible to the
readme guidelines, so I'll think about how to add the
package/extension checking mechanism in at the same time.  (Always
granting that this is of interest to The Powers That Be ;-)

If you are interested, I can send you a version of my FindTCL.cmake
once I get done reworking it to see if it would meet your needs.

Cheers,
CY

P.S. - thank you and the PLplot project for your excellent CMake
scripts - they have been a help to me on several occasions puzzling
out some of the finer points of 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] Possible 'brief' output options for UnixMakefileGenerator

[j s]

Cool,

You might want to put a '^' after each \|, if that is how grep regex handles
it.  I've tended toward egrep which is more perl like when doing more
complicated expressions.  Color is probably lost since it is no longer a
tty.

Juan

On Mon, Dec 20, 2010 at 3:56 PM, Campbell Barton ideasma...@gmail.comwrote:

 @Michael Wild. good point about threaded builds, so I take back the
 bit about Entering directory, then filenames only, nevertheless.
 some way to reduce flooding the console when rebuilding a single file
 would be much appreciated.

 @Juan, from your suggestion, I now use this.

 ---
 #!/bin/bash
 # filters CMake output to be more like nan-makefiles

 FILTER=^Scanning \|Linking \(C\|CXX\) static library \|Built target 
 make $@ | grep --line-buffered -v $FILTER | sed  -e 's/^.*\//  /'
 echo Build Done
 ---

 Jesper Eskilson, agree supporting make -s would be good to have.

 On Mon, Dec 20, 2010 at 10:05 AM, Jesper Eskilson
 jesper.eskil...@iar.com wrote:
  On 12/20/2010 01:01 AM, Campbell Barton wrote:
 
  Hi, I'm STILL trying to have CMake makefiles replace Blender's hand
  crafted makefiles.
 
  Now the main sticking point with 2 other developers is they don't like
  CMakes output, as its overly verbose.
 
  I realize CMake doesn't need to bend to the whim of all users but
  wondering if we could have something like  RULE_BRIEF_OUTPUT
 
  Rather then printing progress and full path for all files it could
  skip percentage and use a relative path for each C file.
 
  I can try submitting a patch but would first like to know if this
  would be acceptable.
 
  I've submitted a bugreport about this:
  http://www.cmake.org/Bug/view.php?id=7062. It was submitted almost two
 years
  ago, so I'm not sure it is getting very much attention by the CMake
 people.
 
  --
  Jesper Eskilson
  Developer
  IAR Systems
 
  ___
  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
 



 --
 - Campbell
 ___
 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] Maintainer for FindX11, FindOpenGL, and FindTCL (and friends)

[Alan W. Irwin]

On 2010-12-20 21:08-0500 Clifford Yapp wrote:


If you are interested, I can send you a version of my FindTCL.cmake
once I get done reworking it to see if it would meet your needs.


Sure.  I would be glad to help test your work for our particular
Tcl/Tk/itcl/itk needs.

Alan
__
Alan W. Irwin

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

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

Linux-powered Science
__
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Possible 'brief' output options for UnixMakefileGenerator

[Campbell Barton]

Slightly improved version which treats Linking lines separately from
source lines.
and its not messed up by threaded builds.

---
#!/bin/bash
# filters CMake output to be more like nan-makefiles

FILTER=^\[ *[0-9]*%] \|^Built target 
make $@ | \
sed -u -e 's/^Linking .*\//Linking /' | \
sed -u -e 's/^.*\//  /' | \
grep --line-buffered -v $FILTER

echo Build Done
---

Output looks like this...

Linking libbf_intern_audaspace.a
  sp_ienv.c.o
  binreloc.c.o
  sp_preorder.c.o
  spanel_bmod.c.o
  glew.c.o
  MT_ExpMap.cpp.o
Linking libextern_binreloc.a
  spanel_dfs.c.o
  spivotL.c.o
Linking libge_videotex.a



On Tue, Dec 21, 2010 at 3:04 AM, j s j.s4...@gmail.com wrote:
 Cool,

 You might want to put a '^' after each \|, if that is how grep regex handles
 it.  I've tended toward egrep which is more perl like when doing more
 complicated expressions.  Color is probably lost since it is no longer a
 tty.

 Juan

 On Mon, Dec 20, 2010 at 3:56 PM, Campbell Barton ideasma...@gmail.com
 wrote:

 @Michael Wild. good point about threaded builds, so I take back the
 bit about Entering directory, then filenames only, nevertheless.
 some way to reduce flooding the console when rebuilding a single file
 would be much appreciated.

 @Juan, from your suggestion, I now use this.

 ---
 #!/bin/bash
 # filters CMake output to be more like nan-makefiles

 FILTER=^Scanning \|Linking \(C\|CXX\) static library \|Built target 
 make $@ | grep --line-buffered -v $FILTER | sed  -e 's/^.*\//  /'
 echo Build Done
 ---

 Jesper Eskilson, agree supporting make -s would be good to have.

 On Mon, Dec 20, 2010 at 10:05 AM, Jesper Eskilson
 jesper.eskil...@iar.com wrote:
  On 12/20/2010 01:01 AM, Campbell Barton wrote:
 
  Hi, I'm STILL trying to have CMake makefiles replace Blender's hand
  crafted makefiles.
 
  Now the main sticking point with 2 other developers is they don't like
  CMakes output, as its overly verbose.
 
  I realize CMake doesn't need to bend to the whim of all users but
  wondering if we could have something like  RULE_BRIEF_OUTPUT
 
  Rather then printing progress and full path for all files it could
  skip percentage and use a relative path for each C file.
 
  I can try submitting a patch but would first like to know if this
  would be acceptable.
 
  I've submitted a bugreport about this:
  http://www.cmake.org/Bug/view.php?id=7062. It was submitted almost two
  years
  ago, so I'm not sure it is getting very much attention by the CMake
  people.
 
  --
  Jesper Eskilson
  Developer
  IAR Systems
 
  ___
  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
 



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





-- 
- Campbell
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v2.8.3-1029-gd8848f9

[Brad King]

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

The branch, next has been updated
   via  d8848f904db5473717f5c1fb99e454e22f4f8a59 (commit)
   via  e1442ac9c16768962b43575ace24c7cf277c2e74 (commit)
   via  42a2e9d91ac3f82562ffe934273dbf0877cdcf26 (commit)
   via  2c2eee61c1fb5bbe7e323699a40463087e808114 (commit)
  from  cd259c747753272516116c7f29736d4b880304bf (commit)

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

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8848f904db5473717f5c1fb99e454e22f4f8a59
commit d8848f904db5473717f5c1fb99e454e22f4f8a59
Merge: cd259c7 e1442ac
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 20 12:41:13 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 20 12:41:13 2010 -0500

Merge topic 'vs10-sln-msbuild-workaround' into next

e1442ac Avoid msbuild .\ idiosyncrasy that builds multiple configs 
(#11594)
42a2e9d Revert Avoid msbuild idiosyncrasy that builds multiple configs 
(#11633)
2c2eee6 Revert Remove unused parameter root in some VS generator methods


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e1442ac9c16768962b43575ace24c7cf277c2e74
commit e1442ac9c16768962b43575ace24c7cf277c2e74
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 20 11:56:18 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Dec 20 11:56:18 2010 -0500

Avoid msbuild .\ idiosyncrasy that builds multiple configs (#11594)

If a .sln file refers to a project file with a leading .\, as in
.\foo.vcxproj instead of just foo.vcxproj or a full path then
msbuild behaves strangely.  Whenever target foo is built as a dependency
of another target, msbuild brings multiple configurations up to date
instead of just the requested configuration!

Avoid a leading .\ in project file references to avoid this behavior.
This alternative fix to that attempted by commit 57e71533 (Avoid msbuild
idiosyncrasy that builds multiple configs, 2010-12-10) avoids use of
full path project file references which vcbuild does not support.

diff --git a/Source/cmGlobalVisualStudio71Generator.cxx 
b/Source/cmGlobalVisualStudio71Generator.cxx
index ba18687..adb5f2f 100644
--- a/Source/cmGlobalVisualStudio71Generator.cxx
+++ b/Source/cmGlobalVisualStudio71Generator.cxx
@@ -182,8 +182,8 @@ cmGlobalVisualStudio71Generator::WriteProject(std::ostream 
fout,
   std::string guid = this-GetGUID(dspname);
   fout  project
 dspname  \, \
-this-ConvertToSolutionPath(dir)
-\\  dspname  ext  \, \{  guid  }\\n;
+this-ConvertToSolutionPath(dir)  (dir[0]? \\:)
+dspname  ext  \, \{  guid  }\\n;
   fout  \tProjectSection(ProjectDependencies) = postProject\n;
   this-WriteProjectDepends(fout, dspname, dir, t);
   fout  \tEndProjectSection\n;
@@ -196,8 +196,8 @@ cmGlobalVisualStudio71Generator::WriteProject(std::ostream 
fout,
 const char* uname = ui-second.c_str();
 fout  Project(\{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\) = \
   uname  \, \
-  this-ConvertToSolutionPath(dir)
-  \\  uname  .vcproj  \, \{
+  this-ConvertToSolutionPath(dir)  (dir[0]? \\:)
+  uname  .vcproj  \, \{
   this-GetGUID(uname)  }\\n
   \tProjectSection(ProjectDependencies) = postProject\n
   \t\t{  guid  } = {  guid  }\n
diff --git a/Source/cmGlobalVisualStudio7Generator.cxx 
b/Source/cmGlobalVisualStudio7Generator.cxx
index d421c7f..51b8918 100644
--- a/Source/cmGlobalVisualStudio7Generator.cxx
+++ b/Source/cmGlobalVisualStudio7Generator.cxx
@@ -299,6 +299,10 @@ void 
cmGlobalVisualStudio7Generator::WriteTargetsToSolution(
 std::string dir = tmf-GetStartOutputDirectory();
 dir = root-Convert(dir.c_str(),
 cmLocalGenerator::START_OUTPUT);
+if(dir == .)
+  {
+  dir = ; // msbuild cannot handle .\ prefix
+  }
 this-WriteProject(fout, vcprojName, dir.c_str(),
*target);
 written = true;
@@ -514,8 +518,8 @@ void 
cmGlobalVisualStudio7Generator::WriteProject(std::ostream fout,
 
   fout  project
 dspname  \, \
-this-ConvertToSolutionPath(dir)
-\\  dspname  ext  \, \{
+this-ConvertToSolutionPath(dir)  (dir[0]? \\:)
+dspname  ext  \, \{
 this-GetGUID(dspname)  }\\nEndProject\n;
 
   UtilityDependsMap::iterator ui = this-UtilityDepends.find(target);
@@ -524,8 +528,8 @@ void 
cmGlobalVisualStudio7Generator::WriteProject(std::ostream fout,
 const char* uname = ui-second.c_str();
 fout  Project(\{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\) = \
   

[Cmake-commits] CMake branch, next, updated. v2.8.3-1031-g6f38d6f

[Bill Hoffman]

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

The branch, next has been updated
   via  6f38d6f0a00b5edba11dcd79445b4675f9d29077 (commit)
   via  f578381e6624b83843a1b9ff079a8073f7bc210f (commit)
  from  d8848f904db5473717f5c1fb99e454e22f4f8a59 (commit)

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

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6f38d6f0a00b5edba11dcd79445b4675f9d29077
commit 6f38d6f0a00b5edba11dcd79445b4675f9d29077
Merge: d8848f9 f578381
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Mon Dec 20 15:34:35 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 20 15:34:35 2010 -0500

Merge topic 'vs2010_header_only_fix' into next

f578381 Fix vs2010 project generation error when HEADER_FILE_ONLY is set.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f578381e6624b83843a1b9ff079a8073f7bc210f
commit f578381e6624b83843a1b9ff079a8073f7bc210f
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Mon Dec 20 15:25:16 2010 -0500
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Mon Dec 20 15:25:16 2010 -0500

Fix vs2010 project generation error when HEADER_FILE_ONLY is set.

In vs2010 a bad project file could be generated if a .c or .cxx file
was marked with HEADER_FILE_ONLY, if it was in a library that contained
both c and c++ code.  This fixes the error in the code, and adds a test
for this case.

diff --git a/Source/cmVisualStudio10TargetGenerator.cxx 
b/Source/cmVisualStudio10TargetGenerator.cxx
index f78aeec..8d3416a 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -700,7 +700,7 @@ void cmVisualStudio10TargetGenerator::WriteCLSources()
 }
   (*this-BuildFileStream )  sourceFile  \;
   // ouput any flags specific to this source file
-  if(cl  this-OutputSourceSpecificFlags(*source))
+  if(!header  cl  this-OutputSourceSpecificFlags(*source))
 {
 // if the source file has specific flags the tag
 // is ended on a new line
diff --git a/Tests/Complex/Executable/CMakeLists.txt 
b/Tests/Complex/Executable/CMakeLists.txt
index 98b29bb..08cc7d4 100644
--- a/Tests/Complex/Executable/CMakeLists.txt
+++ b/Tests/Complex/Executable/CMakeLists.txt
@@ -49,10 +49,17 @@ LINK_LIBRARIES(${COMPLEX_LIBS})
 SET_SOURCE_FILES_PROPERTIES(complex_nobuild.cxx PROPERTIES
   HEADER_FILE_ONLY 1)
 
+# Test forcing a .c file to not build.
+# This makes sure a mixed language library is created
+# with header file only sources
+SET_SOURCE_FILES_PROPERTIES(complex_nobuild.c PROPERTIES
+  HEADER_FILE_ONLY 1)
+
 ADD_EXECUTABLE(A A.cxx A.hh A.h A.txt)
 ADD_EXECUTABLE(complex complex testcflags.c )
 #  Sub1/NameConflictTest.c Sub2/NameConflictTest.c)
-ADD_EXECUTABLE(complex.file complex.file.cxx complex_nobuild.cxx)
+ADD_EXECUTABLE(complex.file complex.file.cxx complex_nobuild.cxx
+  complex_nobuild.c)
 IF(COMPLEX_TEST_CMAKELIB)
   TARGET_LINK_LIBRARIES(complex CMakeLib cmsys cmexpat cmzlib cmlibarchive 
cmbzip2 cmcurl)
 ENDIF(COMPLEX_TEST_CMAKELIB)
diff --git a/Tests/Complex/Executable/complex_nobuild.c 
b/Tests/Complex/Executable/complex_nobuild.c
new file mode 100644
index 000..6b3c2c1
--- /dev/null
+++ b/Tests/Complex/Executable/complex_nobuild.c
@@ -0,0 +1 @@
+#error This file should not be compiled.

---

Summary of changes:
 Source/cmVisualStudio10TargetGenerator.cxx |2 +-
 Tests/Complex/Executable/CMakeLists.txt|9 -
 .../{complex_nobuild.cxx = complex_nobuild.c} |0
 3 files changed, 9 insertions(+), 2 deletions(-)
 copy Tests/Complex/Executable/{complex_nobuild.cxx = complex_nobuild.c} (100%)


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

[Cmake-commits] CMake branch, next, updated. v2.8.3-1033-g7b74942

[Bill Hoffman]

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

The branch, next has been updated
   via  7b74942a96ada709ace7b4b4a0cf7c6e50bd08b8 (commit)
   via  afbfb7ac1d1419062fe9563f7bfddf6da8f39029 (commit)
  from  6f38d6f0a00b5edba11dcd79445b4675f9d29077 (commit)

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

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7b74942a96ada709ace7b4b4a0cf7c6e50bd08b8
commit 7b74942a96ada709ace7b4b4a0cf7c6e50bd08b8
Merge: 6f38d6f afbfb7a
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Mon Dec 20 15:48:27 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 20 15:48:27 2010 -0500

Merge topic 'fix_docs_for_language_property' into next

afbfb7a Add more documentation for LANGUAGE property.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=afbfb7ac1d1419062fe9563f7bfddf6da8f39029
commit afbfb7ac1d1419062fe9563f7bfddf6da8f39029
Author: Bill Hoffman bill.hoff...@kitware.com
AuthorDate: Mon Dec 20 15:46:11 2010 -0500
Commit: Bill Hoffman bill.hoff...@kitware.com
CommitDate: Mon Dec 20 15:46:11 2010 -0500

Add more documentation for LANGUAGE property.

Make it clear that if you set the language on a file, it will be compiled.

diff --git a/Source/cmSourceFile.cxx b/Source/cmSourceFile.cxx
index b793cd5..26328cf 100644
--- a/Source/cmSourceFile.cxx
+++ b/Source/cmSourceFile.cxx
@@ -472,7 +472,9 @@ void cmSourceFile::DefineProperties(cmake *cm)
  What programming language is the file.,
  A property that can be set to indicate what programming language 
  the source file is. If it is not set the language is determined 
- based on the file extension. Typical values are CXX C etc.);
+ based on the file extension. Typical values are CXX C etc. Setting 
+ this property for a file means this file will be compiled. 
+ Do not set this for header or files that should not be compiled.);
 
   cm-DefineProperty
 (LOCATION, cmProperty::SOURCE_FILE, 

---

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


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

[Cmake-commits] CMake branch, next, updated. v2.8.3-1037-g9643572

[Brad King]

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

The branch, next has been updated
   via  96435728e168bc42b03b3824c8acf2284ae6e4f7 (commit)
   via  59925264829e5c9509f505897aafd33478e80cfe (commit)
  from  f7d29ee913d168749ae3f424ce32794182866e12 (commit)

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

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=96435728e168bc42b03b3824c8acf2284ae6e4f7
commit 96435728e168bc42b03b3824c8acf2284ae6e4f7
Merge: f7d29ee 5992526
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 20 17:20:39 2010 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Mon Dec 20 17:20:39 2010 -0500

Merge topic 'ctest-git-send-committer' into next

5992526 CTest: Factor out duplicate Git author/committer code


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=59925264829e5c9509f505897aafd33478e80cfe
commit 59925264829e5c9509f505897aafd33478e80cfe
Author: Brad King brad.k...@kitware.com
AuthorDate: Mon Dec 20 17:16:25 2010 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Dec 20 17:16:25 2010 -0500

CTest: Factor out duplicate Git author/committer code

Factor out date/time format code into FormatDateTime function instead of
duplicating it.

diff --git a/Source/CTest/cmCTestGIT.cxx b/Source/CTest/cmCTestGIT.cxx
index 3456ec4..aa9e55b 100644
--- a/Source/CTest/cmCTestGIT.cxx
+++ b/Source/CTest/cmCTestGIT.cxx
@@ -503,28 +503,7 @@ private:
   this-ParsePerson(this-Line.c_str()+7, author);
   this-Rev.Author = author.Name;
   this-Rev.EMail = author.EMail;
-
-  // Convert the time to a human-readable format that is also easy
-  // to machine-parse: CCYY-MM-DD hh:mm:ss.
-  time_t seconds = static_casttime_t(author.Time);
-  struct tm* t = gmtime(seconds);
-  char dt[1024];
-  sprintf(dt, %04d-%02d-%02d %02d:%02d:%02d,
-  t-tm_year+1900, t-tm_mon+1, t-tm_mday,
-  t-tm_hour, t-tm_min, t-tm_sec);
-  this-Rev.Date = dt;
-
-  // Add the time-zone field +zone or -zone.
-  char tz[32];
-  if(author.TimeZone = 0)
-{
-sprintf(tz,  +%04ld, author.TimeZone);
-}
-  else
-{
-sprintf(tz,  -%04ld, -author.TimeZone);
-}
-  this-Rev.Date += tz;
+  this-Rev.Date = this-FormatDateTime(author);
   }
 else if(strncmp(this-Line.c_str(), committer , 10) == 0)
   {
@@ -532,28 +511,7 @@ private:
   this-ParsePerson(this-Line.c_str()+10, committer);
   this-Rev.Committer = committer.Name;
   this-Rev.CommitterEMail = committer.EMail;
-
-  // Convert the time to a human-readable format that is also easy
-  // to machine-parse: CCYY-MM-DD hh:mm:ss.
-  time_t seconds = static_casttime_t(committer.Time);
-  struct tm* t = gmtime(seconds);
-  char dt[1024];
-  sprintf(dt, %04d-%02d-%02d %02d:%02d:%02d,
-  t-tm_year+1900, t-tm_mon+1, t-tm_mday,
-  t-tm_hour, t-tm_min, t-tm_sec);
-  this-Rev.CommitDate = dt;
-
-  // Add the time-zone field +zone or -zone.
-  char tz[32];
-  if(committer.TimeZone = 0)
-{
-sprintf(tz,  +%04ld, committer.TimeZone);
-}
-  else
-{
-sprintf(tz,  -%04ld, -committer.TimeZone);
-}
-  this-Rev.CommitDate += tz;
+  this-Rev.CommitDate = this-FormatDateTime(committer);
   }
 }
 
@@ -566,6 +524,32 @@ private:
   }
 this-Rev.Log += \n;
 }
+
+  std::string FormatDateTime(Person const person)
+{
+// Convert the time to a human-readable format that is also easy
+// to machine-parse: CCYY-MM-DD hh:mm:ss.
+time_t seconds = static_casttime_t(person.Time);
+struct tm* t = gmtime(seconds);
+char dt[1024];
+sprintf(dt, %04d-%02d-%02d %02d:%02d:%02d,
+t-tm_year+1900, t-tm_mon+1, t-tm_mday,
+t-tm_hour, t-tm_min, t-tm_sec);
+std::string out = dt;
+
+// Add the time-zone field +zone or -zone.
+char tz[32];
+if(person.TimeZone = 0)
+  {
+  sprintf(tz,  +%04ld, person.TimeZone);
+  }
+else
+  {
+  sprintf(tz,  -%04ld, -person.TimeZone);
+  }
+out += tz;
+return out;
+}
 };
 
 char const cmCTestGIT::CommitParser::SectionSep[SectionCount] =

---

Summary of changes:
 Source/CTest/cmCTestGIT.cxx |   72 --
 1 files changed, 28 insertions(+), 44 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org

[Cmake-commits] CMake branch, master, updated. v2.8.3-251-g112ada2

[KWSys Robot]

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

The branch, master has been updated
   via  112ada2eb689793c49c9d4d45dd7b7b9544a9f56 (commit)
  from  34a2dee75d80afe175bd041e26be10da9c09a74f (commit)

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

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=112ada2eb689793c49c9d4d45dd7b7b9544a9f56
commit 112ada2eb689793c49c9d4d45dd7b7b9544a9f56
Author: KWSys Robot kwro...@kitware.com
AuthorDate: Tue Dec 21 00:01:06 2010 -0500
Commit: KWSys Robot kwro...@kitware.com
CommitDate: Tue Dec 21 00:10:48 2010 -0500

KWSys Nightly Date Stamp

diff --git a/Source/kwsys/kwsysDateStamp.cmake 
b/Source/kwsys/kwsysDateStamp.cmake
index 7fbfda4..433a86f 100644
--- a/Source/kwsys/kwsysDateStamp.cmake
+++ b/Source/kwsys/kwsysDateStamp.cmake
@@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR  2010)
 SET(KWSYS_DATE_STAMP_MONTH 12)
 
 # KWSys version date day component.  Format is DD.
-SET(KWSYS_DATE_STAMP_DAY   20)
+SET(KWSYS_DATE_STAMP_DAY   21)

---

Summary of changes:
 Source/kwsys/kwsysDateStamp.cmake |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


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