Re: [cmake-developers] Debugger for CMake

[Jean-Christophe Fillion-Robin]

Hi Justin, Adam et al,

made a proof of concept for a debugger integrated into CMake


Very nice to see someone moving this forward :+1



> Wish this existed since forever.


FWIW, you may want to also look at what was done by Matt here:
https://github.com/thewtex/cmakedbg

Hth
Jc


-- 
+1 919 869 8849 <%28919%29%20869-8849>
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Git for windows patch

[Jean-Christophe Fillion-Robin]

Hi,

> The existence of \bin is there only for backward
-compatibility

I guess we could also add "Git/usr/bin" to the suffixes so that it prefer
newer version first ?

PATH_SUFFIXES Git/usr/bin Git/cmd Git/bin

Hth
Jc

On Fri, Jan 15, 2016 at 11:24 AM, Paul Smith  wrote:

> On Fri, 2016-01-15 at 10:05 -0500, Shawn Waldon wrote:
> > Looking at the git installation, there is another executable
> > "C:\Program Files (x86)\Git\cmd\git.exe", but I have never pointed
> > CMake at that one.  What is the difference between the two?  I can
> > change the patch to use the other one, but I'd like to understand why
> > it is necessary.
>
> There is no difference between them.  When you install Git for Windows
> the installer gives a choice of three different ways to set up %PATH%.
>
> One way is to not add anything to %PATH%: then git is only available
> from within the Git bash shell not from within command.com shell.
>
> The second way is to make git, only (plus a few helpers like gitk,
> start-ssh-agent, etc.) available on %PATH%: then git is available from
> command.com but none of the other UNIX tools like find, diff, etc. are
> available from command.com (only from Git shell).  In this install
> method the \cmd directory is added to %PATH%.
>
> The last way is to allow git plus all the ming32 versions of UNIX tools
> that come with Git to be available to command.com.  In this install
> method both \cmd AND \usr\bin are added to %PATH%.
>
> The existence of \bin is there only for backward
> -compatibility, because some people coming from older versions of Git
> for Windows might be referencing it.  It shouldn't be used anymore by
> modern installs (it contains bash.exe and sh.exe both of which are in
> \usr\bin, and git.exe which is in \cmd).
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>



-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [Development] [ANNOUNCE] DaD's House! (Beta)

[Jean-Christophe Fillion-Robin]

Hi Konstantin,

Thanks for sharing your work with the community.

Given the exhaustive list of modules provided within the installers, I
can appreciate the effort.

That said, as you may know, downloading unsigned binaries to build
applications is not an option for a lot of us.

Here are few initial suggestions to improve your platform:

  * transition the website to https
  * reference the version of each packages/modules bundled in the
respective installers
  * provide the a how to understand the different between
stable/testing/unstable
  * document the convention to integrate the different module in our
existing project. For example, for CMake did you write a
Config.cmake file with each project [1] ? And similar question
for qmake ?

Good luck,
Jc

[1] http://www.cmake.org/cmake/help/git-next/manual/cmake-packages.7.html

On Thu, Sep 10, 2015 at 10:12 AM, Konstantin Podsvirov
 wrote:
> 10.09.2015, 16:41, "Curtis Mitch" :
>>> From: Konstantin Podsvirov [mailto:konstan...@podsvirov.pro]
>>>
>>> By clicking on the link, you will be able to get the installer is the same
>>> as the QtSDK and a few clicks to get the binaries, libraries and linking
>>> headers of any of the participating modules.
>>
>> But what am I even clicking the link for? What service does this thing 
>> provide?
>
> For example, You want to create a very large and useful application which 
> uses a lot of dependencies.
> And you want to deploy it on the Windows.
>
> You go to the site:
>
> http://dad.podsvirov.pro
>
> Download appropriate to your development environment setup.
>
> Quickly and easily install any required dependent modules and receives a 
> development environment, local deployment and testing.
>
> When you're finished designing, you can create compatible with this 
> environment the installer to install your application on other machines.
>
> Main technologies:
> * Development languages: C, C++ (Qt, Qml, Quick) and other
> * Project management: CMake, but can use other
> * Creating installer based QtIFW (CMake allows you to automate the process of 
> creating an installer).
>
> I answered Your question?
>
> Regards,
> Konstantin Podsvirov
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers



-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Exported targets with imported dependencies in CMake 3.0

[Jean-Christophe Fillion-Robin]

.. and whenever possible the FindXXX.cmake should defined imported targets.

Jc


On Thu, Mar 6, 2014 at 9:38 AM, Philipp Möller bootsare...@gmail.comwrote:

 Stephen Kelly steve...@gmail.com writes:

  Philipp Möller wrote:
  It would be great, if I could export imported targets and if CMake could
  walk the dependency tree automatically and import those targets on an
  as-needed basis.
 
  Part of the problem is that the place where you import your dependent
  targets from (and the locations calculated) are not necessarily the same
 for
  your downstreams.

 I understand the issue and have been fighting it in versions prior 3.0
 as well. It also arises if you simply export targets that have been
 target_link_librarie'd against full library paths returned by a
 find_package.

 That's why I thought some build-in functionality could be helpful for
 this, e.g. exporting and imported target would lead to a definition in
 the exports file that automatically triggers a corresponding
 find_package call.

  You export your targets to and -exports file, and presumably you import
 that
  in a -config file. In the same config file, you should add code to find
 your
  dependencies too.
 
 
 http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#creating-packages
 
  The find_dependency macro can help with forwarding some find_package
  arguments.
 
 
 http://www.cmake.org/cmake/help/v3.0/module/CMakeFindDependencyMacro.html

 The documentation is a little sparse, but I think I understand the
 purpose. I still need to traverse IMPORTED_LINK_INTERFACE_LIBRARIES and
 figure out which of the list members constitutes a target that needs to
 trigger a find_dependency and what a full library path is, correct?

 I can also not rely on a find_package call to actually produce imported
 targets and need to ship the code that turns the results of find_package
 in targets.

 Thanks for your help,
 Philipp

 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] New EVIS parser moving forward (3.1)

[Jean-Christophe Fillion-Robin]

On Fri, Feb 21, 2014 at 12:05 PM, Ben Boeckel ben.boec...@kitware.comwrote:

 On Fri, Feb 21, 2014 at 08:38:35 +0100, Rolf Eike Beer wrote:
   Are there any other corner cases I should consider banning as well?
 What
   about behavior that should be allowed that currently isn't?
 
  If this patch is the right place to address this is not clear to me, but
 I
  mention them anyway.

 These are both if()-related behaviors. The EVIS parser *only* expands
 ${} and @@ variables. The treat-literal-as-variable name is implemented
 by cmIfCommand::GetVariableOrString by which point quoted-ness has been
 lost. The hex support would be in cmSystemTools::VersionCompare; the
 parser doesn't care at all if you use literal hex values. Hint: There
 are no integers in CMake; they're all strings and interpreted with atoi
 when necessary.

  -if a string is quoted, it may still be expanded as a variable name as I
 have
  heard, i.e. those 2 may act as the same:
 
  if (a STREQUAL b)
  if (${a} STREQUAL ${b})

 Worse, the former may also really be either of:

  if (a STREQUAL ${b})
  if (${a} STREQUAL b)

 depending on which is defined.

  I would not expect such behavior, in fact I consider this
 counterintuitive.

 I agree in general, however, my CMake style is to quote all variable
 expansions unless I want argument splitting. This rule would break code
 like this:

 if (CMAKE_${LANG}_FLAGS)
 endif ()

 which would be unfortunate, IMO.


As a quick check, I ran the following search on CMake code base and it
returns nothing:

   cd ./CMake-src
   ack --cmake \(\s*\[a-zA-Z0-9]+\$

Also nothing for Slicer, ITKv4, VTK6, ...

If possible, not having implicit expansion for quoted argument would be
great at make things more intuitive and practical.



 I don't think quoted isn't expanded
 unless it is a single word with a nested variable expansion is an
 obvious rule either. We could certainly make it so that anything with
 spaces isn't expanded which should take care of some of the more
 egregious cases. Maybe we should just deprecate implicit expansion in
 if()? That wouldn't be that hard of a policy to implement. I don't know
 how happy people would be with it though.






 Looking at this code, this expansion is missing --warn-uninitialized
 support. I don't know if it is worth it to implement it here since I
 imagine the false-positives would be legion.

  -support for hex numbers would be cool, especially for parsing the
 version
  numbers out of header files (like OpenSSL).

 This would be beneficial, I agree.

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




-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Reduce output of install step

[Jean-Christophe Fillion-Robin]

Hi Folks,

Removing extra outputs is good. Would it make sense for Kevin to push a
topic to next ? Should a policy be added to avoid breaking system that
relied on the stdout ?

Jc


On Mon, Feb 17, 2014 at 9:51 AM, Kevin Burge kcbu...@gmail.com wrote:

 At Brad King's request, I am posting this here.

 I opened a feature request for reducing the output of the installation
 step.  I don't think it is necessary (or even helpful) to output Up to
 date for targets that are up to date during the install step.  There can
 only be three outcomes to the install step: a) the target is installed, b)
 the target failed to be installed or updated, or c) the target is up to
 date.  I think it makes the most sense to just log a message for a) and b),
 not c).  If we compare this to the build step, the build step does not
 notify of targets that are up to date.

 We recently switched to ninja which is extremely fast.  I never noticed
 how much time I spent waiting for the install MESSAGES to finish scrolling
 by, until I patched cmake and noticed the difference.  When building in
 emacs, or remotely, this can be a significant amount of data going over the
 wire (especially for a remote desktop session) for absolutely no benefit.

 Thanks for the consideration.

 http://www.cmake.org/Bug/view.php?id=14757


 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Release Notes

[Jean-Christophe Fillion-Robin]

Very nice.


On Fri, Feb 7, 2014 at 1:42 PM, Brad King brad.k...@kitware.com wrote:

 On 02/04/2014 12:06 PM, Brad King wrote:
  I'm working on the notes for 3.0.0 by hand

 I've added release notes for 3.0:

  Help: Add CMake 3.0 Release Notes
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9860f90

 Please proofread and check for your changes.
 (I'm excluding most minor/internal bug fixes.)

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




-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] add_custom_command differences in tests

[Jean-Christophe Fillion-Robin]

Agreed. Is there an issue in the tracker to document that problem ?


On Fri, Feb 7, 2014 at 3:05 PM, Steve Wilson ste...@wolfram.com wrote:


 On Feb 7, 2014, at 10:14 AM, Steve Wilson ste...@wolfram.com wrote:


 On Feb 6, 2014, at 10:12 PM, Ben Boeckel ben.boec...@kitware.com wrote:

 On Thu, Feb 06, 2014 at 17:30:11 -0700, Steve Wilson wrote:

 I have my topic branch with the add_custom_command changes to include
 the CONFIG keyword working.The CMake binary produced from the
 build will correctly generated build systems that have custom commands
 with the CONFIG keyword.   I'm having trouble writing tests for the
 changes though.   When I run add_custom_command with the CONFIG
 keyword in the test suite the CONFIG keyword does not work.

 I need a little guidance with the test suite.   I'm not super familiar
 with CTest so I'm not sure where to look next to find the problem.
 So my question:  Why would add_custom_command behave differently in
 the tests than in regular build system generation?


 I have been able to determine that the code isn't working because it seems
 that when running from ctest, cmake seems to be running in a
 configuration-less mode. Ie CMAKE_BUILD_TYPE/CMAKE_CONFIGURATION_TYPE are
 not set regardless of the -C option passed to ctest.I would have
 thought that the build configuration of the test would match the
 configuration set with 'ctest -C .'

 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Reverse logic

[Jean-Christophe Fillion-Robin]

Re-including the list.

You could also find more details reading the documentation of the if
command. See http://www.cmake.org/cmake/help/git-master/command/if.html


On Wed, Jan 29, 2014 at 7:40 PM, Rob McDonald rob.a.mcdon...@gmail.comwrote:

 Yep, that does it for me.  Sneaky...

 Rob



 On Wed, Jan 29, 2014 at 4:23 PM, Jean-Christophe Fillion-Robin 
 jchris.filli...@kitware.com wrote:

 Hi Rob,

 What about:

 if( NOT USE_SYSTEM_FOO)
 # Build my own FOO
 endif()

 Hth
 Jc




-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] RFC: add version to project() call

[Jean-Christophe Fillion-Robin]

I would vote for (2), that way people using the latest and greatest of
CMake won't have to enable any variable and it will work out of the box.
Jc


On Tue, Jan 28, 2014 at 9:10 AM, Brad King brad.k...@kitware.com wrote:

 On 01/23/2014 04:08 PM, Alexander Neundorf wrote:
  Any more comments left ?

 Moving the discussion from


 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9156/focus=9158

 back to the thread where it belongs:

 On 01/27/2014 04:58 PM, Stephen Kelly wrote:
  Though I still don't like the behavior in the topic with project()
 commands
  without a specified VERSION and the
  CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND variable etc. I don't see
 why
  all the complexity is needed.
 
  From what I understand, the reason it was added is related to using
  add_subdirectory to add a self-contained/standalone project to host
  buildsystem.

 My main concern that the VERSION complexity solves is for changing
 behavior of existing projects that are *not* modified at all.  We've
 established that a project() without VERSION needs to unset the
 PROJECT_VERSION variables because otherwise they would not correspond
 to the current PROJECT_NAME.  However, an existing project could do

  # CMakeLists.txt
  project(Top)
  set(PROJECT_VERSION 1.0.0)
  add_subdirectory(Sub)

  # Sub/CMakeLists.txt
  project(Sub)
  message(STATUS Top version = ${PROJECT_VERSION})

 Since previous versions of CMake documented no special behavior
 for the PROJECT_VERSION variable this code is completely fine
 now, but would suddenly change in behavior if project() started
 to unset PROJECT_VERSION.

 So our options are

 (1) Design new behavior in a way that requires a change to the
 project to activate.

 (2) Add a policy.  The policy should only trigger when the
 project() command is about to unset a PROJECT_VERSION
 variable that was set by user code and not by a previous
 project() command.

 -Brad

 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Review Request for ExternalProjects: Only update certain git submodules

[Jean-Christophe Fillion-Robin]

Hi Folks,

That would be a great contribution.

I will give a try to the patch by the beginning of next week. This is
something that would be useful for CTK [1].

Thanks for working on this,
Jc

[1] http://www.commontk.org


On Wed, Jan 15, 2014 at 10:03 AM, Brad King brad.k...@kitware.com wrote:

 On 01/10/2014 08:58 AM, David Cole wrote:
  Not that I'm a skeptic (well, ok, maybe a smidge...) but I would
  like to have *independent* confirmation from somebody else that it at
  least works for them before we merge this into CMake.

 The silence in this thread indicates no one is planning to step forward
 for this.

 David, if the implementation looks correct, the smoke test case works,
 and no existing test cases regress then I think this is ready.  Please
 shepherd this topic through 'next'.

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




-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] Change default standard library implementation before used by compiler ?

[Jean-Christophe Fillion-Robin]

Hi Folks,

For both Slicer and SimpleITK, there is currently no support for the clang
c++ standard library new implementation [1] that is now used by default on
Maverick.

It means that we currently expect our users to build the project by passing
the flag:
 -DCMAKE_CXX_FLAGS_INIT:STRING=-stdlib=libstdc++
as explained in [2]

To allow our users to build without explicitly passing flag, what would be
recommended approach ?

I was thinking about the following and would like to get your inputs /
suggestions:

1) Add a compile test so that the flag could be updated before the first
call to project()/enable_langage(). Is this possible ?

2) Wrap the project into a superbuild structure ... that could work but
would be a ugly hack.

Thanks for your help,
Jc

[1] http://libcxx.llvm.org/

[2]
http://slicer-devel.65872.n3.nabble.com/Mavericks-with-SimpleITK-tt4030687.html
-- 
+1 919 869 8849
-- 

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] RFC: add version to project() call

[Jean-Christophe Fillion-Robin]

Would it make sense to have project(Foo VERSION 1.2.3) set the variables:
  ${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)

That way, the variable would remain even if project is called with VERSION
in sub directory.

Jc



On Fri, Jan 10, 2014 at 9:49 AM, Brad King brad.k...@kitware.com wrote:

 On 01/06/2014 04:41 PM, Alexander Neundorf wrote:
  I modified write_basic_package_version_file() accordingly, so that you
 can now
  simply do
 
  project(Foo VERSION 1.2.3)
 
  ...
 
  write_basic_package_version_file(FooConfigVersion.cmake
   COMPATIBILITY AnyNewerVersion)
 
  and this will use the version number from the project() call
 automatically (if
  no VERSION has been given explicitely).

 One problem left to address is what to do when a project() command is
 invoked in a subdirectory.  It will set PROJECT_NAME, PROJECT_SOURCE_DIR,
 and PROJECT_BINARY_DIR but it should also *unset* the PROJECT_VERSION_
 variables if no VERSION argument is provided.  Otherwise the version
 values will not be consistent with the project name.

 -Brad

 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] RFC: add version to project() call

[Jean-Christophe Fillion-Robin]

Great.

Having both:
  PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)
  ${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)
is the way to to go.



On Fri, Jan 10, 2014 at 11:41 AM, Matthew Woehlke 
mw_tr...@users.sourceforge.net wrote:

 On 2014-01-10 11:01, Jean-Christophe Fillion-Robin wrote:

 Would it make sense to have project(Foo VERSION 1.2.3) set the
 variables:
${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)

 That way, the variable would remain even if project is called with VERSION
 in sub directory.


 How is that different? Do you mean to drop the PROJECT_VERSION_{...}
 entirely? That doesn't seem desirable for symmetry with the other
 PROJECT_{...} variables.

 I think I'm with Brad; set the PROJECT_VERSION_{...} and
 ${PROJECT_NAME}_VERSION_{...} (note; no extra literal 'PROJECT') as usual.
 Always. Whether or not VERSION was specified (i.e. unset the corresponding
 variables in such case).

 Folks that use the PROJECT_{...} forms hopefully know what they are doing,
 otherwise people are hopefully using the ${PROJECT_NAME}_{...} forms
 instead.


 Related: Do these affect the version properties of libraries? (Because
 OTOH if it does, I can imagine wanting to say VERSION once at the root and
 have it inherit downwards unless overridden. Maybe though that's a reason
 for it to not do so.)

 --
 Matthew


 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Minor regression in --version results for CMake 2.8.12.1 (A FALSE ALARM)

[Jean-Christophe Fillion-Robin]

Hi Marcel,

You could use the -p option.

For example:

$ type -p ld
/usr/bin/ld

Hth
Jc


On Fri, Dec 6, 2013 at 3:28 AM, Marcel Loose lo...@astron.nl wrote:

 On 05/12/13 18:27, Matthew Woehlke wrote:
  On 2013-12-05 02:36, Alan W. Irwin wrote:
  Sorry, this turned out to be a false alarm. Despite which cmake
  telling me I was using cmake-2.8.12.1 [snip]
 
  ...which is, of course, why you should always use type in bash
  rather than which :-). type, being a shell built-in, will tell you
  what bash will *actually* run, hashing - and shell builtins, and
  functions, and aliases - included.
 
 Hmm, interesting. I didn't know the type command. However, is there a
 way to easily parse the output of type? The which command simply
 returns the command it will execute or an empty string if there's no
 match. With type, I've seen different outputs, like:

 $ type ls
 ls is aliased to `ls --color=auto'

 $ type rm
 rm is hashed (/bin/rm)

 $ type ld
 ld is /usr/bin/ld

 This make it pretty hard to parse :(

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




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments

[Jean-Christophe Fillion-Robin]

Hi Danielle,

We use the macro a lot in project like Slicer and CTK.
This is a great improvement of the CMakeParseArguments module. Thanks for
working on this.

Jc


On Wed, Nov 27, 2013 at 10:40 AM, Brad King brad.k...@kitware.com wrote:

 On 11/27/2013 9:54 AM, Daniele E. Domenichelli wrote:
  Any comment?

 I was hoping others that use this module would respond here.

  Can I merge it to next?

 Go ahead and merge it to 'next' for testing.  I will review it
 there when I return from vacation next week.

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




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Review Request: Topic ExternalProject_GitUpdate

[Jean-Christophe Fillion-Robin]

Hi Daniele,

After copying the ExternalProject.cmake in the Module directory of the
CMake installation I used for daily work, I didn't see any issue /  side
effect.

Considering the external projects I am dealing with always specify the
SHA1, I didn't have a chance to explicitly test the case if(is_remote_ref)
... 

Hth
Jc


On Fri, Nov 22, 2013 at 1:06 PM, Brad King brad.k...@kitware.com wrote:

 Jc, Matt,

 On 11/18/2013 10:10 AM, Jean-Christophe Fillion-Robin wrote:
  Will give a try and let you know how it goes.
 [snip]
 On 11/18/2013 12:40 PM, Matt McCormick wrote:
  I have checkout out the branch, will test it locally, and make any
  notes of unexpected behavior.

 Thanks for looking at this topic.  Once you have reported back
 from local experimentation we can proceed with it.

 Thanks,
 -Brad




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Review Request: Topic ExternalProject_GitUpdate

[Jean-Christophe Fillion-Robin]

Hi Daniele,

This is a great improvement. It is so easy to loose local change to an
external project A made while debugging/tweaking it for a better
interaction into an other project B with B depending on A.

Will give a try and let you know how it goes.

Thanks
Jc




On Mon, Nov 18, 2013 at 6:19 AM, Daniele E. Domenichelli 
daniele.domeniche...@gmail.com wrote:

 Hello,

 Please review the topic ExternalProject_GitUpdate

 ExternalProject handles git remote branches by commit hash. Due to this,
 the git repository ends in detached states, and local commits are
 discarded.

 This patch uses git pull --rebase for remote branches instead of git
 checkout. If there are local changes, git stash is used to save the
 changes and restore them after the pull. If any of these operation
 fails, it tries to restore the original status and exits with a fatal
 error, asking the user to resolve the conflicts manually.

 This also makes the behaviour of ExternalProject using git more similar
 to the svn version, and probably more likely to what the user expects by
 setting GIT_TAG to a branch.


 Cheers,
  Daniele
 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui

[Jean-Christophe Fillion-Robin]

+1

I like the idea of the [Apply Command Line Parameters button appear
whenever -Dvar=value parameters were passed.]

Would also be nice if parameter like -G ... could also be considered for
the first configuration. Within some of our project, I envision user
downloading a bat script named BuildMyProjectWithVS2008.bat that would
pass all the expected option to cmake-gui. Aware the same could be done
directly with cmake or ccmake .. but visual studio user often expects UI
with buttons



On Wed, Nov 6, 2013 at 3:33 PM, Brad King brad.k...@kitware.com wrote:

 On 11/06/2013 02:55 PM, physhh . wrote:
  How should we proceed? I think Mathew understood what's my problem.

 This thread has covered use cases in which it makes sense to apply
 (or not apply) command-line parameters in cmake-gui for various
 cases.  No one automatic behavior is going to satisfy everyone.

 Nobody picked up on Matthew's suggestion here:


 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8553/focus=8553

 which was:

 On 11/05/2013 02:56 PM, Matthew Woehlke wrote:
  What about having an option (e.g. a combo box) when to apply command
  line options?
 
  - At startup (only initial / specified on command line build directory)
  - New projects (when no CMakeCache.txt exists yet, but also at startup)
  - Unconfigured projects (per my original proposal)
  - Always (i.e. when selecting a different build directory)
 
  The default could be 'new projects' if no build directory is specified
  on the command line (probably you are giving common rather than
  project specific options in this case), otherwise 'at startup' (more
  chance options are project specific).

 Another approach is to have an Apply Command Line Parameters
 button appear whenever -Dvar=value parameters were passed.
 This will allow users to put their command-line options into
 effect at any time without changing any settings.  The button
 should not pay attention to command-line options that set the
 source/build trees.

 If that is not sufficient then Matthew's proposed combo box
 can be used to select when command-line parameters are applied
 automatically.

 -Brad
 --

 Powered by www.kitware.com

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

 Kitware offers various services to support the CMake community. For more
 information on each offering, please visit:

 CMake Support: http://cmake.org/cmake/help/support.html
 CMake Consulting: http://cmake.org/cmake/help/consulting.html
 CMake Training Courses: http://cmake.org/cmake/help/training.html

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

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




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui

[Jean-Christophe Fillion-Robin]

Would it makes sense to have cmake-gui behaving like ccmake ? After all
there are both UI.

It would accept the same set of options:

  -C initial-cache  = Pre-load a script to populate the cache.
  -D var:type=value = Create a cmake cache entry.
  -U globbing_expr  = Remove matching entries from CMake cache.
  -G generator-name = Specify a makefile generator.
  -T toolset-name   = Specify toolset name if supported by
generator.


Jc


On Mon, Nov 4, 2013 at 5:29 PM, Matthew Woehlke matthew.woeh...@kitware.com
 wrote:

 On 2013-11-04 15:47, David Cole wrote:

 My question is still not answered completely:

 When should the new variable be added? On startup is not really
 possible because it might be the case that your src/binary directory
 is not set properly.

 So you would agree that it makes sense to do it on configure but
 only if the cache is empty? This will not allow to overwrite the
 variable via parameter but I guess that usecase is not very
 common?


 On startup is the only time it does make sense. After that, the user
 should be in charge, and the command line settings should not be
 re-applied again after a user makes an edit. You don't need the
 src/binary directories set properly necessarily in order to add a cache
 entry to the UI.


 There are two mostly separate issues here.

 As far as the bug, the ccmake behavior is (IMO, but seems generally
 shared) is just wrong. physhh's questions (above) don't apply to this case
 because there is no concept of interactively selecting the build directory
 in ccmake. So fixing this is, if not easy, at least easy to understand how
 it should behave.

 As far as cmake-gui, there are no backward compatibility issues because
 right now it just doesn't support -D at all.

 It does however get more complicated...

 - What should happen with a -D option if there is not initially a build
 directory selected?

 - What should happen if the wrong build directory is initially selected
 and subsequently changed? It seems non-desirable here to forget -D (etc.)
 entirely at that point.


  ccmake and cmake-gui *should* behave (in *my* opinion) as follows:
 - on startup, load the CMakeCache.txt values (if there are any) from the
 previous run
 - then apply the -D arguments so that any -D arguments given on the
 command line overwrite previous cache entries (just like command line
 cmake does already)
 - then put the user in charge and wait for user input


 I suppose if I were writing the patch, I would have cmake-gui remember
 whatever -D/-U/etc. options are given and apply them to any build directory
 when it is selected, after loading the cache (if any). But *don't* pass
 them on the cmake (except inasmuch as the initial cache will contain them,
 modulo any changes the user made in the mean time).

 IOW, if I specify a -D to cmake-gui, change that value, then change to
 some other build directory, that -D would reset to the value from the
 command line. This is consistent with the current behavior that any other
 changes to the cache of the initial build directory are also lost.

 Hmm... a corner case comes to mind, however; if I configure build
 directory A after changing a -D value, then switch to build directory B,
 then back to A, I probably don't want to reapply the -D. So maybe cmake-gui
 would keep track of what build directories have been configured in that
 instance and not apply -D/etc. to them. (However, it's probably not very
 common for that to happen.)

 Make sense?

 --
 Matthew


 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Continuous CMake documentation of 'next' and 'master'

[Jean-Christophe Fillion-Robin]

That is awesome ! :)


On Fri, Nov 1, 2013 at 11:37 AM, Brad King brad.k...@kitware.com wrote:

 Hi Folks,

 We now publish CMake documentation built from 'next':

  http://www.cmake.org/cmake/help/git-next/

 and from 'master':

  http://www.cmake.org/cmake/help/git-master/

 updated every 10 minutes from each branch.

 There is also a continuous dashboard submission section:

  http://open.cdash.org/index.php?project=CMake#Continuous_Help

 that builds just the documentation for rapid turnaround.

 These links now appear in the developer workflow instructions:

  http://www.cmake.org/Wiki/CMake/Git/Develop#Merge_a_Topic_for_Testing

 Please follow the links from those instructions when you modify
 documentation to make sure it builds and renders correctly.

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




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Testing Groups

[Jean-Christophe Fillion-Robin]

Hi Andreas,

Sounds like a very interesting idea.

Instead of introducing the GROUP parameter in the add_test command, may
be the LABEL could be re-used ?

Would also be nice to consider the concept of resource locking while
thinking about this. [1]

Jc

[1] http://www.cmake.org/Bug/view.php?id=14077



On Mon, Jun 10, 2013 at 3:19 AM, Andreas Schneider a...@cryptomilk.orgwrote:

 Hi,

 I'm currently working on some libraries [1] which allows you advanced
 testing
 of daemons. Especially ones which require a network in testing. However for
 using this I need some features in CMake. This should be a discussion about
 these features. Maybe others have ideas and comments.

 What I would like to have is a feature to group tests. By default
 everything
 is in a standard test group. But you can define a special one:

 add_test(NAME name [CONFIGURATIONS [Debug|Release|...]]
  [GROUP test_group]
  [WORKING_DIRECTORY dir]
  COMMAND command [arg1 [arg2 ...]])


 For a test group I need a way to define a setup/teardown command. Some
 tests
 might require a special setup on the machine to be able to run correctly.
 Like
 setting up a fake network.

 set_test_group_properties(PROPERTIES
 SETUP command [arg1 [arg2 ...]]
 TEARDOWN command [arg1 [arg2 ...]]
 ENVIRONMENT env)

 The setup function is called before the first test of the group is executed
 and the teardown functions after the last test finished. The environment
 should be obvious.


 Please comment.


 -- andreas



 [1] http://git.cryptomilk.org/projects/socket_wrapper.git/

 --
 Andreas Schneider   GPG-ID: F33E3FC6
 www.cryptomilk.orga...@cryptomilk.org

 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] compile_options command

[Jean-Christophe Fillion-Robin]

+1
That would be a great features.
Jc

--
Sent from my mobile device
On Jun 3, 2013 1:12 PM, Brad King brad.k...@kitware.com wrote:

 On 06/03/2013 12:38 PM, Stephen Kelly wrote:
   add_compile_options(-Wundef)

 IMO this name is good because it looks like a generalized version
 of add_definitions which people already use for this purpose.

 -Brad
 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Safe source list GLOBs

[Jean-Christophe Fillion-Robin]

Hi Folks,

Being able to activate the dynamic globing on a per-directory or per-target
or per-glob call basis would be nice. Coupled with automoc feature of Qt,
that would simplify things greatly.

I would be happy to test patches on our large scale project 3DSlicer.
See https://github.com/Slicer/Slicer

Thanks
Jc


On Thu, May 30, 2013 at 11:50 AM, Matthew Woehlke 
matthew.woeh...@kitware.com wrote:

 On 2013-05-30 08:47, Wojciech Knapik wrote:

 Working with make taught me once and for all, that functions like
 [execute_process] should be avoided whenever possible. A build tool

 creates files from files via the means of targets. So if you want to
 use a tool like this effectively, you should use targets to achieve
 your goals, otherwise unexpected things will happen.


 That is true in most cases. However it is sometimes necessary, e.g. run
 some tool to get its version string (because that information is not
 otherwise available) in order to determine the correct install destination
 for some files.

 While add_custom_command is to be preferred in almost all cases, there are
 definitely correct uses for execute_process, usually similar to uses for
 e.g. try_compile (i.e. gathering system configuration information).

 (Most recently, I am using it to parse a Shiboken typesystem XML to
 determine the list of source files that will be created by binding
 generation in order to feed them to add_library. This would be impossible
 at build time short of using an external project.)

 --
 Matthew


 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] BundleUtilities and @rpath

[Jean-Christophe Fillion-Robin]

Hi Clinton,

This is to create bundle that use @rpath. Particularly useful when you want
to support plugin.

Let me know what you think, I just updated my the toy project.
Other list of changes have been pushed into CMake stage:
http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/tweak-bundleutilities-for-rpath

Thanks
Jc


On Thu, May 2, 2013 at 11:51 AM, Clinton Stimpson clin...@elemtech.comwrote:

 On Wednesday, April 24, 2013 06:45:11 PM Jean-Christophe Fillion-Robin
 wrote:
  Hi Folks,
 
  I have been working on improving BundleUtilities and GetPrerequisites
  module so that it can be used to easily fixup a MacOSX bundle using
 @rpath.
 
  The set of changes I would like to propose is here:
 
 https://github.com/jcfr/CMakeBundleUtilitiesExample/compare/f7a594ffba72b8cb
  83df9a166d7887bedc49f38b...75fa538
 
  To try out the change, you could build the small project I created for
 that
  purpose: https://github.com/jcfr/CMakeBundleUtilitiesExample#readme
 
  Let me know what you think.
 
  Thanks
  Jc

 Is it to help make the same @executable_path based bundles but support
 copying
 in libraries and frameworks that used @rpath and change them over to be
 @executable_path based?

 Or is this to help create bundles that result in the use of @rpath?

 --
 Clinton Stimpson
 Elemental Technologies, Inc
 Computational Simulation Software, LLC
 www.csimsoft.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




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Code Changes to support C++ Windows Forms

[Jean-Christophe Fillion-Robin]

Hi John,

Seems your topic isn't available on the CMake stage:
http://cmake.org/gitweb?p=stage/cmake.git

I would suggest you push your topic on github instead. The stage is used by
module maintainer or CMake core developers [1]

Hth
Jc

[1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer


On Mon, Apr 29, 2013 at 8:36 AM, john.farr...@helleboreconsulting.comwrote:

 I created a topic called WindowsFormsResx following the developer guide
 instructions and have committed my staged changes and a test project.  I
 don't know how to send out a link to this, but would be happy to do so if
 someone pointed me in the right direction.

 - John



 On 2013-04-28 20:46, Jean-Christophe Fillion-Robin wrote:

 Hi John,

 Seems you forgot to send a link to the associated topic.

 Jc

 On Sun, Apr 28, 2013 at 10:20 PM, 
 john.farrier@**helleboreconsulting.comjohn.farr...@helleboreconsulting.com
 wrote:

  Hello all!  New CMake developer here!

 I have modified the latest version of CMake from Git to be able to use
 .resx files and integrate them into Visual Studio, perform the correct
 associations, and enable use of the Visual Studio designer for Windows
 Forms applications after a solution and projects are configured by CMake.
  The changes were fairly minimal, but really help me out!  I have a project
 that is mostly cross-platform, but there are a few plugins that are
 windows-specific.  I wanted to use CMake to build and manage the project,
 but when CMake configured the windows GUI's, I would lose all of the
 designer information, which is totally unacceptable for ever having to make
 a change to the GUI.  This change is targeted specifically at C++ Windows
 Forms applications using CLI.  I'd like to push these changes up, so
 feedback is welcome!

 - John Farrier

 --

 Powered by www.kitware.com [1]

 Visit other Kitware open-source projects at http://www.kitware.com/**
 opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html[2]

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


 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers[4]


 --
 +1 919 869 8849


 Links:
 --
 [1] http://www.kitware.com
 [2] 
 http://www.kitware.com/**opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html
 [3] 
 http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ
 [4] http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**
 developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Code Changes to support C++ Windows Forms

[Jean-Christophe Fillion-Robin]

Hi John,

Seems you forgot to send a link to the associated topic.

Jc


On Sun, Apr 28, 2013 at 10:20 PM, john.farr...@helleboreconsulting.comwrote:

 Hello all!  New CMake developer here!

 I have modified the latest version of CMake from Git to be able to use
 .resx files and integrate them into Visual Studio, perform the correct
 associations, and enable use of the Visual Studio designer for Windows
 Forms applications after a solution and projects are configured by CMake.
  The changes were fairly minimal, but really help me out!  I have a project
 that is mostly cross-platform, but there are a few plugins that are
 windows-specific.  I wanted to use CMake to build and manage the project,
 but when CMake configured the windows GUI's, I would lose all of the
 designer information, which is totally unacceptable for ever having to make
 a change to the GUI.  This change is targeted specifically at C++ Windows
 Forms applications using CLI.  I'd like to push these changes up, so
 feedback is welcome!

 - John Farrier



 --

 Powered by www.kitware.com

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

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

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/cgi-**bin/mailman/listinfo/cmake-**developershttp://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers




-- 
+1 919 869 8849
--

Powered by www.kitware.com

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

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

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers