[cmake-developers] [ANNOUNCE] CMake 3.4.0-rc1 is now ready!

2015-10-06 Thread Robert Maynard 
I am proud to announce the first CMake 3.4 release candidate.

Sources and binaries are available at:
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.4

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.4/release/3.4.html

Some of the more significant features of CMake 3.4 are:

* The "if()" command learned a new "TEST" operator that evaluates to
  true if a given test name has been defined by the "add_test()"
  command.  See policy "CMP0064".

* The "install(DIRECTORY)" command "DESTINATION" option learned to
  support "generator expressions".

* The "install(FILES)" command "DESTINATION" option learned to
  support "generator expressions".

* CMake learned to honor "*.manifest" source files with MSVC tools.
  Manifest files named as sources of ".exe" and ".dll" targets will be
  merged with linker-generated manifests and embedded in the binary.


Deprecated and Removed Features:

* The "CMakeExpandImportedTargets" module is now documented as
  deprecated.  See module documentation for an explanation.

* The "CMAKE_USE_RELATIVE_PATHS" variable no longer has any effect.
  Previously it was partially implemented and unreliable.

CMake 3.4 Release Notes
***

Changes made since CMake 3.3 include the following.


New Features



Generators
--

* The "Visual Studio 14 2015" generator learned to select a Windows
  10 SDK based on the value of the "CMAKE_SYSTEM_VERSION" variable and
  the SDKs available on the host.

* CMake learned rudimentary support for the Apple Swift language.
  When using the "Xcode" generator with Xcode 6.1 or higher, one may
  enable the "Swift" language with the "enable_language()" command or
  the "project()" command (this is an error with other generators or
  when Xcode is too old).  Then one may list ".swift" source files in
  targets for compilation.


Commands


* The "find_program()" command learned a "NAMES_PER_DIR" option to
  consider all given "NAMES" in each directory before moving on to the
  next directory.

* The "get_filename_component()" command learned a new "BASE_DIR"
  subcommand.  This is used to specify a base directory when
  calculating an absolute path from a relative path.

* The "if()" command learned a new "TEST" operator that evaluates to
  true if a given test name has been defined by the "add_test()"
  command.  See policy "CMP0064".

* The "install(DIRECTORY)" command "DESTINATION" option learned to
  support "generator expressions".

* The "install(FILES)" command "DESTINATION" option learned to
  support "generator expressions".

* The "string()" command learned a new "APPEND" subcommand.


Variables
-

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools like distcc and ccache along with the
  compiler for "C" and "CXX" languages.  See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* New "CMAKE_LINK_SEARCH_START_STATIC" and
  "CMAKE_LINK_SEARCH_END_STATIC" variables were introduced to
  initialize the "LINK_SEARCH_START_STATIC" and
  "LINK_SEARCH_END_STATIC" target properties, respectively.


Properties
--

* Visual Studio Generators learned to support additonal target
  properties to customize projects for NVIDIA Nsight Tegra Visual
  Studio Edition:

  * "ANDROID_ANT_ADDITIONAL_OPTIONS"

  * "ANDROID_ARCH"

  * "ANDROID_ASSETS_DIRECTORIES"

  * "ANDROID_JAR_DEPENDENCIES"

  * "ANDROID_JAR_DIRECTORIES"

  * "ANDROID_JAVA_SOURCE_DIR"

  * "ANDROID_NATIVE_LIB_DEPENDENCIES"

  * "ANDROID_NATIVE_LIB_DIRECTORIES"

  * "ANDROID_PROCESS_MAX"

  * "ANDROID_PROGUARD"

  * "ANDROID_PROGUARD_CONFIG_PATH"

  * "ANDROID_SECURE_PROPS_PATH"

  * "ANDROID_SKIP_ANT_STEP"

  * "ANDROID_STL_TYPE"

* The "ARCHIVE_OUTPUT_DIRECTORY", "LIBRARY_OUTPUT_DIRECTORY", and
  "RUNTIME_OUTPUT_DIRECTORY" target properties learned to support
  "generator expressions".

* The "SOURCE_DIR" and "BINARY_DIR" target properties were
  introduced to allow project code to query where a target is defined.

* The "OUTPUT_NAME" target property and its variants learned to
  support "generator expressions".

* A "TARGET_MESSAGES" global property was added to tell the Makefile
  Generators whether to generate commands to print output after each
  target is completed.

* On Windows with MS-compatible tools, CMake learned to optionally
  generate a module definition (".def") file for "SHARED" libraries.
  See the "WINDOWS_EXPORT_ALL_SYMBOLS" target property.


Modules
---

* The "ExternalProject" module "ExternalProject_Add()" function
  "GIT_SUBMODULES" option now also limits the set of submodules that
  are initialized in addition to the prior behavior of limiting the
  set of submodules that are updated.

* The "ExternalProject" module learned new "USES_TERMINAL" arguments
  for giving steps exclusive terminal access.  This is useful with the
  "Ninja"

Re: [cmake-developers] CXX_STANDARD and linking

2015-10-06 Thread Brad King 
On 10/04/2015 10:47 AM, Stephen Kelly wrote:
> So, is this thread really about a bug, or is it a feature request? 

I think it has become a feature request to select link flags for language
standard levels.  It is conflated with a bug fix because the link flags
are needed to support existing features on Solaris.

> Perhaps those commits should be reverted. I see no reason for SolarisStudio 
> on linux to behave any differently than on solaris, so the commit relating 
> to that is probably not appropriate.

I don't want CMake to generate broken builds by default.  We *know* it
goes wrong on Solaris and cannot possibly work without user intervention.
If a problem comes up on Linux too we can deal with it as necessary.

> I wrote here some ideas of a design for specifying the standard library to 
> use: 
> 
>  
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13284/focus=13296

Is that the right link?  I don't see discussion of -stdlib= in that message.

> Perhaps, rather than passing CMAKE_CXX11_EXTENSION_COMPILE_OPTION to the 
> linker, we should work more on a design like the above way to specify a 
> standard library. 

Yes, but the -std= and -stdlib= flags are different from the full
LINK_OPTIONS discussion because they are meant specifically for the
front end and not for the linker (never "-Wl,").  Also they need
to be selected by CMake rather than propagated as a flag specified
by project code.

> The compile features can imply a default and a set of allowed alternatives 
> (for example, compiling with cxx_static_assert implies the use of stdlibc++ 
> or libc++ with Clang by default but there is a way to use the other 
> instead).  The COMPATIBLE_INTERFACE features may also be used to ensure that 
> targets which link together all use the same standard library.

Originally I was thinking we should just use the same -std= for linking
that we do for compilation, but don't we currently support compiling
different targets at different standard levels and then linking them?
In that case we will certainly need more sophisticated logic for
selecting the link flag.

BTW, I noticed in cmLocalGenerator::AddCompileOptions that we currently
mutate the configure step result by setting target properties like
_STANDARD during generation.  Also, this is done with one "config"
value which may not be appropriate in multi-config generators.

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

Re: [cmake-developers] [Review request] TopicFind GTK2_sigc++_c++11

2015-10-06 Thread Brad King 
On 10/06/2015 07:51 AM, Daniele E. Domenichelli wrote:
> According to the sigc++ changelog, starting with version 2.5.1, sigc++
> requires c++11 enabled, hence this patch.

Thanks.

> +* Starting with sigc++ 2.5.1, c++11 must be enabled in order to use
> +  sigc++.

Generally we don't do release notes for bug fixes, but this is somewhat
of a new feature since it enables C++11 automatically for the client
project.  Please word the release note as a feature that the imported
target provides.

> +set_property(TARGET GTK2::sigc++ PROPERTY 
> INTERFACE_COMPILE_FEATURES cxx_alias_templates cxx_lambdas)

Nice.  Please add a comment to explain that these are the features
needed by clients in order to include the project headers.

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

Re: [cmake-developers] CXX_STANDARD and linking

2015-10-06 Thread Ben Boeckel 
On Sun, Oct 04, 2015 at 16:47:40 +0200, Stephen Kelly wrote:
> The existing CMake feature deals with compilation, but does not deal with 
> linking. 

A generic target_link_options() is necessary for other things as well,
such as:

  * -fsanitize=address needs to be passed to the linker to add -lasan
(similar for other sanitizers);
  * -pg -ftest-coverage -fprofile-arcs needs to be passed to the
linker for adding profiling information.

--Ben
-- 

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] added get_git_revision and get_git_branch commands as follow-up to cm...@cmake.org

2015-10-06 Thread Ben Boeckel 
On Mon, Oct 05, 2015 at 12:50:41 +0200, Daniel Wirtz wrote:
> thanks for the feedback, i've included most of it.
> 
> Regarding the configure/build issue: that indeed is inconvenient and may 
> cause irritation. on the other side, if there has been git activity 
> fussing with any source files affecting the build, cmake will run again 
> and hence capture the possibly new git info. so the case where you 
> change the revision after configure to an extent where cmake will not 
> automatically re-run is uncommon, at least for my guessing.
> however, i've included an explicit warning in the docs to raise awareness.

Well, without depending on every file in the source tree, it will just
be wrong rather than causing excess configure runs. Adding something
like "configure this file at build time" setup would need to be the
basis though (basically porting and cleaning up sprokit_configure_file()
into CMake as deferred_configure_file() or something similar would work).

> i'm happy to provide a suitable procedure that is flexible enough; 
> providing scripts that configure files (like with sprokit) seems too 
> specific as people might want to have a single "config.h" file or so 
> containing more than just the git info.

The sprokit mechanism configures any file using code to determine some
of the variables at build time. It is by no means limited to just header
files. The code injection is a little clunky (being a string and all),
but it could also be changed to an include() statement with an extra
depends on that included file. In fact, with include(), adding support
for SVN, Mercurial and others would be pretty simple as well rather than
duplicating all this for each revision system.

> i've thought about the possibility to generate an explicit 
> "git_version.h" file to include, but that 1) restricts possible 
> languages and 2) will require an extra build target that is run each 
> build etc. any thoughts?

Well, you will indeed never have a "nothing to do" build with such a
target, but such information is effectively derived from "this depends
on every file in the tree tracked by git as well as the .git/HEAD,
.git/index, and .git/refs/tags/* files" so "always something to do"
isn't that far off. The step (in sprokit) takes ~0 time to run
anyways[1], so speed isn't an issue.

--Ben

[1]45 build trees took < 2 seconds, so figuring for some overhead for
exec() of ninja itself and ninja scanning, the overhead for checking the
git revision is < .05s for a smallish source tree. Something like
webkit's git mirror could take a while though.
-- 

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] automatically download library

2015-10-06 Thread Ryan Schmidt 

On Oct 6, 2015, at 7:22 AM, Марсель Галимуллин wrote:

> I'm student of the University LETI and as a masrer's thesis I want to develop 
> an extension to CMake. It is expected that this extension will automatically 
> download missing library if instruction such as «find_package (Boost 
> COMPONENTS system thread REQUIRED)» can not find the package. Could you give 
> me some advices where to begin and which the best direction to design, 
> develop and whether to do it?

If you need that for some special purpose, go for it, but it's probably not a 
behavior most users would expect, and it's definitely a behavior that would 
have to be disabled in any software installed by a package management system. 
(The package management system would want to be in control of what gets 
downloaded.)


-- 

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

[cmake-developers] automatically download library

2015-10-06 Thread Марсель Галимуллин 
Hello!I'm student of the University LETI and as a masrer's thesis I want to develop an extension to CMake. It is expected that this extension will automatically download missing library if instruction such as «find_package (Boost COMPONENTS system thread REQUIRED)» can not find the package. Could you give me some advices where to begin and which the best direction to design, develop and whether to do it? --Kind regards,Marsel Galimullin. 
-- 

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] Issue on CMAKE_OSX_SYSROOT

2015-10-06 Thread Brad King 
On 10/06/2015 09:49 AM, Francesco Romano wrote:
> - Compilation of the project. 
> I want the user to be able to compile the project on its machine
> (so build system = deployment system). Of course I can document
> that he has to explicitly pass the variable to cmake, but it
> does not seem too user friendly to me

Your project should not be setting CMAKE_OSX_DEPLOYMENT_TARGET
in its code.  If you don't set this then CMAKE_OSX_SYSROOT is
not needed.  Both are meant to be set by end users.  If the
deployment target is their own machine then neither needs to
be set and it should just work.

> - Brew formula.
> I have to use ruby to detect the user platform and configure
> the arguments to cmake accordingly.

If the build targets the current system then again there is no
need to set either variable.  Or, you can set both by using a
symbolic SDK name rather than the path.  For example:

 -DCMAKE_OSX_DEPLOYMENT_TARGET=10.9
 -DCMAKE_OSX_SYSROOT=macosx10.9

> I also want to add that this issue arose with Xcode 7.
> Indeed Apple ships now (first the first time) only the 10.11 SDK,
> even if the system is 10.10. And this is what is causing the issue,
> because cmake automatically set the deployment target to match
> the sdk and not the build system.

Okay, that looks like the underlying issue.  The
Modules/Platform/Darwin-Initialize.cmake module will have
to be taught about this case to do the right thing by default
if it does not already.

Gregor, do you mind taking a look at this?

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

[cmake-developers] [Review request] TopicFind GTK2_sigc++_c++11

2015-10-06 Thread Daniele E. Domenichelli 
Hello,

Starting with some recent update on my system that updated sigc++ from
2.4.0 to 2.6.1, I noticed that a few GTK2Targets tests depending on
sigc++ are failing.
According to the sigc++ changelog, starting with version 2.5.1, sigc++
requires c++11 enabled, hence this patch.


  FindGTK2: Enable c++11 for sigc++ 2.5.1 or later
  https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=f06bd1e


Can you please review it?



Cheers,
 Daniele
-- 

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] automatically download library

2015-10-06 Thread Daniel Wirtz 

Hey,

so i've been working on a quite large build system for OpenCMISS, which 
in turn consumes about 30 external packages itself.
the main repo (and cmake logic) can be found here: 
https://github.com/OpenCMISS/manage (branch v1.0).
feel free to have a look around and use some of the logic. essentially, 
it performs checks using find_package and then downloads

the components from our github repos & builds them if not found.

however, such an integration with many many components, difficult 
interoperability and (thus far) unclear origin of the packages that 
should be automatically
installed (you'll need some sort of database / list for that) is quite a 
thing for a masters thesis. not to speak of incompatibilities with other 
system libraries that those

automatically downloaded packages might want to use.
as for ideas, there's the maven concept: https://maven.apache.org/. it's 
not cmake, but it also deals with the "is package there, if not, i know 
where to get & build it" issue.


good luck :-)

Dr. Daniel Wirtz
Dipl. Math. Dipl. Inf.
SRC SimTech
Pfaffenwaldring 5a
+49 711 685 60044

On 10/06/2015 02:22 PM, Марсель Галимуллин wrote:


Hello!
I'm student of the University LETI and as a masrer'sthesis I want to 
developan extension to CMake. It is expected that this extension will 
automatically download missinglibrary ifinstruction such as 
«find_package (Boost COMPONENTS system thread REQUIRED)» can not find 
the package. Could you give me some advices where to begin and which 
the best direction to design, developand whether to do it?


--
Kind regards,
Marsel Galimullin.




-- 

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] script mode current directory

2015-10-06 Thread Brad King 
On 10/05/2015 04:36 PM, Tamás Kenéz wrote:
> Here is the patch which documents and tests those 4 variables

Great, thanks.  Applied with minor tweaks:

 Document and test CMAKE_[CURRENT_](BINARY|SOURCE)_DIR in script mode
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8bb908b1

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

Re: [cmake-developers] Issue on CMAKE_OSX_SYSROOT

2015-10-06 Thread Francesco Romano 
Thanks Brad for the answer.

Maybe I did not understand correctly your answers.
I’ll use as an example two use cases (which by the way are where we detected 
the issue)
- Compilation of the project. 
I want the user to be able to compile the project on its machine (so build 
system = deployment system). Of course I can document that he has to explicitly 
pass the variable to cmake, but it does not seem too user friendly to me
- Brew formula.
I have to use ruby to detect the user platform and configure the arguments to 
cmake accordingly.

I also want to add that this issue arose with Xcode 7. Indeed Apple ships now 
(first the first time) only the 10.11 SDK, even if the system is 10.10. And 
this is what is causing the issue, because cmake automatically set the 
deployment target to match the sdk and not the build system. The compiled 
applications are not executable by the system then.

Hope I clarified :)

Ciao
Francesco



> On 05 Oct 2015, at 17:27, Brad King  wrote:
> 
> On 10/03/2015 05:00 AM, Francesco Romano wrote:
>> I don't know if this is the right mailing list
> 
> This is a good place since it concerns a new OS X release.
> 
>> I needed to set the variable `CMAKE_OSX_DEPLOYMENT_TARGET` to 10.10 and this
>> was done after the first "project" call.
> 
> That should be right, though I cannot say for sure without seeing the code.
> Typically we do not have the project code set this value but instead add
> it to the CMake command line when building for deployment:
> 
> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.10
> 
>> elseif("${CMAKE_GENERATOR}" MATCHES Xcode
>>   OR CMAKE_OSX_DEPLOYMENT_TARGET
>>   OR CMAKE_OSX_ARCHITECTURES MATCHES "[^;]"
>>   OR NOT EXISTS "/usr/include/sys/types.h")
>> 
>> Now, the question is: why the Unix Makefile should  not  need the
>> variable "CMAKE_OSX_SYSROOT" but only if the deployment target is not set?
>> Shouldn't be correct to set anyway the sysroot (which by the way can be
>> easily found because Xcode is present on the machine)?
> 
> The Unix Makefiles generator also supports the Xcode command-line tools,
> third-party compilers, etc. that all build for the host system.  If you
> are explicitly building for deployment then you should specify
> 
> -DCMAKE_OSX_SYSROOT=/path/to/10.10/SDK
> 
> The Xcode generator searches for a sysroot even when not using an
> explicit deployment target because Xcode always wants one specified
> and does not support the pure command-line tools.
> 
> -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://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] automatically download library

2015-10-06 Thread Brad King 
On 10/06/2015 08:22 AM, Марсель Галимуллин wrote:
> automatically download missing library if instruction such as
> find_package (Boost COMPONENTS system thread REQUIRED) can not
> find the package.

In general this is outside the scope of a build system and falls
in the domain of package management.  I do not think this approach
is a good fit for CMake's find_package infrastructure as proposed.

FYI, CMake already has some features to help people build projects
without manually installing all dependencies ahead of time.  See
ExternalProject and superbuilds for example:

 http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html

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

Re: [cmake-developers] Add more options for NSIS installer artwork

2015-10-06 Thread Brad King 
On 10/05/2015 06:59 PM, Colin Tracey wrote:
> I sent a similar patch as plain text in an email to the list last
> Friday, but after observing the email traffic It looks like you
> prefer attachments.  I also added documentation to this one.

Inline patches are fine and slightly preferred for me personally
because it is easier to quote hunks while commenting.  I simply
hadn't caught up with all list traffic yet.

Anyway, the change looks good and I've applied it with minor
tweaks:

 CPackNSIS: Add options to set the bitmap for NSIS installer left side
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3758af12

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

Re: [cmake-developers] [Review request] TopicFind GTK2_sigc++_c++11

2015-10-06 Thread Brad King 
On 10/06/2015 12:20 PM, Daniele E. Domenichelli wrote:
> I updated the topic according to your comments. The new commit is this:
> 
>   FindGTK2: Enable c++11 for sigc++ 2.5.1 or later
>   https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=33eb8fa

LGTM.

> I'm not 100% sure that there aren't other c++11 features used

Future versions could add more anyway.  This list should be
sufficient to get C++11 enabled.

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