Re: [cmake-developers] productbuild: Installing to absolute system path or to user home path

[David Cole via cmake-developers]

According to the docs, the INSTALL command uses the absolute path if
it is given as the DESTINATION, so  it should work.
https://cmake.org/cmake/help/latest/command/install.html

Did you try using a double quoted string, instead of escaping the
space with a backslash?

I think this should work for the absolute one:
INSTALL( ... DESTINATION "/abs/path/to/some folder")

For the one in the home directory, I'm not sure if a string that
starts with "~" is considered absolute or not, so it may or may not
end up where you expect it. Can you resolve it before hand with a
get_filename_component call, (or otherwise), and pass in a string that
begins with "/" ...?


Hope this helps,
David C.


On Mon, Oct 28, 2019 at 4:36 PM Roman Wüger  wrote:
>
> 
>
> Hello,
>
>
>
> I tried to install a file/directory with productbuild on macOS which is 
> generated with CPack
>
> The most of the files are installed correctly, but I have two problems:
>
>
>
> If I want to install to “/Library/Application\ 
> Support/Adobe/Lightroom/Modules”
> If I want to install to the users modules folder “~/Library/Application\ 
> Support/Adobe/Lightroom/Modules”
>
>
>
> How can I archive these two?
>
>
>
> I already tried the following with no luck:
>
> install(DIRECTORY 
> $/${CMAKE_PROJECT_NAME}.lrplugin
>
> DESTINATION /Library/Application\ 
> Support/Adobe/Lightroom/Modules)
>
>
>
> install(DIRECTORY 
> $/${CMAKE_PROJECT_NAME}.lrplugin
>
> DESTINATION ~/Library/Application\ 
> Support/Adobe/Lightroom/Modules)
>
>
>
> Best Regards
>
> Roman
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
-- 

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

Re: [cmake-developers] cmake-file-api and CTest

[David Cole via cmake-developers]

The return code indicates a stack overflow. Let's hope it is not intended.

https://stackoverflow.com/questions/50562192/process-finished-with-exit-code-1073740791-0xc409-pycharm-error


On Thu, Aug 22, 2019 at 7:16 AM Nagy-Egri Máté Ferenc via
cmake-developers  wrote:
>
> Hi!
>
>
>
> Someone managed to beat me to creating a CTest adapter for the Test Explorer 
> UI extension to Visual Studio Code, so instead of writing on from scratch, 
> I’ll start contributing to it. There is an „autorun test” property which can 
> be triggered when the adapter sees fit. I wanted to create file watchers for 
> the executable AND any files the test depends on, based on the REQUIRED_FILES 
> property of the test. However, when the REQUIRED_FILES property is set on a 
> test and I ask for –show-only=json-v1 ctest.exe fails with exit code 
> -1073740791 and outputs nothing. Was this intended?
>
>
>
> Cheers,
>
> Máté
>
>
>
> Feladó: Nagy-Egri Máté Ferenc
> Elküldve: 2019. július 9., kedd 9:41
> Címzett: Kyle Edwards; CMake fejlesztők
> Tárgy: RE: [cmake-developers] cmake-file-api and CTest
>
>
>
> Hi Kyle,
>
>
>
> I’ve never contributed to CMake before. I once wanted to enchance the 
> makefile generators with batch-mode support and built CMake myself and walked 
> through the code in debug mode to see what it does. I identified the entry 
> point where I should’ve placed my code, but essential it would’ve require a 
> major rewrite of the makefile generators to enable deferred makefile 
> generation. Daunted by the amount of work, I figured it was not worth the 
> effort. (It was primarily motivated by NMake.)
>
>
>
> I’ll try giving the file API a spin and see if I understand the code enough 
> to be able to add new queries and extract tests from the internal 
> representation. I was hoping to not have to touch CMake itself for this 
> summer project, but it seems that’s the first step.
>
>
>
> Cheers,
>
> Máté
>
>
>
> Feladó: Kyle Edwards
> Elküldve: 2019. július 8., hétfő 15:56
> Címzett: Nagy-Egri Máté Ferenc; CMake fejlesztők
> Tárgy: Re: [cmake-developers] cmake-file-api and CTest
>
>
>
> On Sun, 2019-07-07 at 09:04 +, Nagy-Egri Máté Ferenc via cmake-
>
> developers wrote:
>
> > Hi!
>
> >
>
> > I am trying to cook a CTest back-end to the Test Explorer UI
>
> > extension for VS Code as a summer project and I thought of using the
>
> > new cmake-file-api for it. The docs however are understandably scarce
>
> > and I could not muster how to obtain tests and not targets. Is it
>
> > possible with this initial API design? If not, is my best bet to
>
> > invoke CTest and parse the console output?
>
>
>
> FileAPI does not currently list CTest tests, though I agree that this
>
> would be a good thing to have, perhaps for 3.16. Is this something
>
> you'd be willing to help with?
>
>
>
> Kyle
>
>
>
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
-- 

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

Re: [cmake-developers] Is email notification of a failed CMake dashboard possible?

[David Cole via cmake-developers]

Before you login, it's just a "login" link. Once you've logged in, it
becomes a "My CDash" link.

On Sun, May 26, 2019 at 2:34 PM Alan W. Irwin
 wrote:
>
> On 2019-05-26 11:07+1000 Craig Scott wrote:
>
> > Notifications for builds are controlled through CDash. You can adjust your
> > CDash notifications to suit your preferences. Go to CDash, click on "My
> > CDash". You should see a list of "My Projects" and "Public Projects".
> > Subscribe to a project and it will appear under your "My Projects" area if
> > it isn't there already. For each subscribed project, you should see an icon
> > next to it under the Actions column which allows you to edit your
> > subscription and from there you can control what you receive email
> > notifications for. I'm not sure if there is a way to limit your
> > notifications to just certain sites though. You may need to ask on the
> > CDash mailing list for help with that.
>
> Hi Craig:
>
> Thanks for trying to help me, but I can find no mention of "My CDash"
> at either  or
> .  So can you be more
> specific about what URL I need to consult to control my notification
> preferences at **?
>
> Alan
>
> >
> >
> > On Sun, May 26, 2019 at 7:54 AM Alan W. Irwin 
> > wrote:
> >
> >> With a lot of initial configuration help from Brad King, I have been
> >> automatically submitting a Nightly dashboard for CMake (including the
> >> PLplot contract test) for some time now (see the "merlin" results at
> >>  and
> >> ).  On extremely rare
> >> occasions there is a failure in either of my CMake or KWSYS
> >> dashboards.  Is it possible for me to set up e-mail notification of
> >> such failures (and successes at first to make sure notification
> >> works), and if so, how?
> >>
> >> Alan
> >> __
> >> Alan W. Irwin
> >>
> >> Programming affiliations with the FreeEOS equation-of-state
> >> implementation for stellar interiors (freeeos.sf.net); the Time
> >> Ephemerides project (timeephem.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
> >>
> >> 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:
> >> https://cmake.org/mailman/listinfo/cmake-developers
> >>
> >
> >
> > --
> > Craig Scott
> > Melbourne, Australia
> > https://crascit.com
> >
> > Get the hand-book for every CMake user: Professional CMake: A Practical
> > Guide 
> >
>
> __
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.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
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
-- 

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 

Re: [cmake-developers] Preferred case for macro names?

[David Cole via cmake-developers]

I would just like to point out that some modules (ExternalData,
ExternalProject, to name two specific examples) adopted the convention
to prefix all their provided function names with the module name and
an underscore: for example, ExternalProject_Add and
ExternalData_Expand_Arguments.

These functions adopt a mixed-case function naming convention, since
the module name is mixed case, and since module names are file names,
and some file systems have case sensitive file names .. they
should stay that way regardless of any convention you may like to try
to adopt elsewhere.


David C.

On Tue, Nov 13, 2018 at 5:36 AM Eric Noulard  wrote:
>
>
>
> Le mar. 13 nov. 2018 à 10:41, Marc CHEVRIER  a écrit 
> :
>>
>> I agree as well that trying to distinguish macros from functions is not a 
>> good idea because functions can act in the same way as macros (i.e. changing 
>> calling environment) but with a better control over environment changes 
>> (changes are done explicitly by using 'set(... PARENT_SCOPE)').
>>
>> so also +1 for lower case for every function, macro or builtin. And good 
>> point to standardize  macro or function OPTION to UPPERCASE.
>>
>> Now, for variables, the problem is a bit different because they are case 
>> sensitive: 'set(my_var ...)' and 'set (MY_VAR ...)' will create two 
>> different variables.
>
>
> Yes damn right.
>
>>
>> My personal tendency is to use lower case for local variables and upper case 
>> for global variables. May be we can normalize variables to upper case 
>> regarding global variables used by CMake itself (which is globally the 
>> current rule).
>
>
> Having a convention for local is nice and I tend to prefix with _ (single or 
> double) variables that should be local.
> lowercasing locals is fine too, however I think that enforcing casing on 
> "user-defined" variable may not be desirable, concerning CMAKE_ CTEST_ and 
> CPACK_
> I guess they already are all UPPERCASE so we may stick with this as a 
> convention?
>
> A small quote to the cmake-format 
> (https://github.com/cheshirekow/cmake_format) tool which is trying to 
> beautify CMakeLists.txt, I'm not using it on complex projects
> because it still has some issues but I find it otherwise useful.
>
>
> --
> Eric
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
-- 

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

Re: [cmake-developers] Link element in C# project causing issues with binary dir

[David Cole via cmake-developers]

The code looks wrong like this, too:

You shouldn't strip the source directory from the path of the file
name unless the character after the source directory is "/" or "\\",
should you? If the thing you're trying to end up with is a path name
to the file under the source directory, then this is incorrect in this
case.

I'm guessing you have "layout-composer" and "layout-composer-build" as
sibling directories of each other?



On Fri, Jun 29, 2018 at 4:12 PM Robert Dailey  wrote:
>
> According to the code, the logic is wrong:
>
> void cmVisualStudio10TargetGenerator::GetCSharpSourceLink(
>   cmSourceFile const* sf, std::string& link)
> {
>   std::string f = sf->GetFullPath();
>   if (!this->InSourceBuild) {
> const std::string stripFromPath =
>   this->Makefile->GetCurrentSourceDirectory();
> if (f.find(stripFromPath) != std::string::npos) {
>   link = f.substr(stripFromPath.length() + 1);
>   if (const char* l = sf->GetProperty("VS_CSHARP_Link")) {
> link = l;
>   }
>   ConvertToWindowsSlash(link);
> }
>   }
> }
>
>
> It's checking if the whole binary dir is rooted where source dir is,
> instead it should be checking each file to see if they are descendents
> of CMAKE_BINARY_DIR, and if so, use the , otherwise don't use
> it. This allows  to be variable between files in the project.
>
> Does anyone know if there's already a function in CMake for checking
> if a file is in the CMAKE_BINARY_DIR? Or do I have to write my own
> code for that check?
>
> On Fri, Jun 29, 2018 at 3:08 PM, Robert Dailey  
> wrote:
> > When I use configure_file() to generate AssemblyInfo.cs, which I allow
> > to go to the CMAKE_CURRENT_BINARY_DIR, Visual Studio 2017 reports:
> >
> > Warning The file
> > 'E:\code\layout-composer-build\Properties\AssemblyInfo.cs' could not
> > be added to the project.  Cannot add a link to the file
> > E:\code\layout-composer-build\Properties\AssemblyInfo.cs. This file is
> > within the project directory tree.
> >
> > When I define a target using C# language, it adds this for files under
> > the same directory as the generated CSPROJ file:
> >
> > 
> >   build\Properties\AssemblyInfo.cs
> > 
> >
> > The CSPROJ file is located: 
> > E:\code\layout-composer-build\LayoutComposer.csproj
> >
> > Is there a way to make the  element not needed in this scenario?
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
-- 

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

Re: [cmake-developers] CMake build with static crt and static QtDialog not linking

[David Cole via cmake-developers]

I had a project where I had to do this in the main.cpp file to get it
to link with static Qt on Windows:

#ifdef _WIN32
#ifdef QT_STATIC
Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin)
#endif
#endif

Those unresolved externals you posted look familiar... Does this fix it?


HTH,
David C.

On Tue, Feb 13, 2018 at 11:28 AM, Stuermer, Michael  SP/HZA-ZSEP
 wrote:
> I try to do a CMake build with static C runtime and a static Qt 5.10.0 build
> to avoid runtime errors when giving the binaries to colleagues. The Visual
> Studio version is 2017. AFAIK the official CMake builds already use this
> “full-static-build” scheme. However I end up with some linking errors of 137
> unresolved external symbols starting with
>
>
>
> unresolved external symbol __imp_OpenThemeData referenced in function
> "public: virtual void __cdecl QVistaBackButton::paintEvent
>
>
>
> and ending with
>
>
>
> unresolved external symbol NetApiBufferFree referenced in function "public:
> static bool __cdecl QFileSystemEngine::uncListSharesOnServer
>
>
>
> Are there some tricks I have to do to get this working? I changed all /MD
> flags manually to /MT, but nothing else so far.
>
>
>
> PS: I’m not sure how the mailing list is handled compared to the gitlab
> instance. Would this be something I should open an issue for? I personally
> do not see it as an issue (which means “something has to be changed in the
> code” for me). Or is the mailing list more or less a leftover from
> before-gitlab times?
>
>
>
> Best regards,
>
> Michael
>
>
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
>
-- 

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

Re: [cmake-developers] CTest script and many subprojects

[David Cole via cmake-developers]

I think your analysis is correct.

You could try doing a ctest_submit after each ctest_test call. Not
sure if you could get "correct" results with that technique. I run
some scripts that do something similar without subproject involved,
and it mostly works, but messes up the +/- tests passed and failed
since last submission data on the instance of CDash I'm using.

If you would like it to work differently than it presently does, it
would probably involve some changes to ctest. Making it do what you
want it to do and becoming a contributor is probably the quickest way
to achieve that.


HTH,
David C.



On Fri, Sep 1, 2017 at 2:36 PM, Wouter Klouwen
 wrote:
> Hi all,
>
> I've been having some success with CTest and am interested in using
> CDash as well.
>
> In order to generate some nice output, sub projects seem to be the best
> way of presenting the data in CDash for our setup. This setup is perhaps
> summed up by having one projects that contains a few hundred projects.
> Most of these "sub projects" are normal CMake projects.
>
> Now, in the normal build, we have a `check` target. This is powered by
> having tests added with add_test() and this check target invokes CTest
> with a script that contains the setting of the SubProject property.
>
> This produces the expected Test.xml with the SubProject tag. When
> submitting these to CDash, it produces the right subproject view and the
> expected aggregate view.
>
> The next step is that we have code on devices for which we cross compile
> and we want to use the same mechanism here in order to execute tests
> when installed on our target devices.
>
> Before I started the CDash work, I was able to generate CTest files
> which contain the add_test() and set_tests_properties() in order to run
> the tests on the devices. This was then invoked with the
> DartConfiguration.tcl and ctest -T Test
>
> Perhaps not ideal as it involves generated many CTestTestfile.cmakes,
> but this was able to execute the several hundreds of tests with the
> appropriate load balancing and produce one giant Test.xml.
>
> In order to switch to generate Test.xml files with SubProject tags this
> mechanism needs to be switched to using a CTest script.
>
> As SubProject is a global property, I assume this needs to be unique for
> each invocation of ctest_test().
> Unfortunately putting multiple ctest_test() calls in one CTest script
> seems to result in one Test.xml, which is the last project run. The test
> of the output is overwritten.
>
> It seems the only way I can make this work is by having a script which
> effectively creates a new CTest script for each subproject, and moves
> the produced Test.xml out of the way for the next run.
> Is this right?
>
> I hope this all makes sense.
>
> Thanks in advance,
> W
> This transmission contains information that may be confidential and contain
> personal views which are not necessarily those of YouView TV Ltd. YouView TV
> Ltd (Co No:7308805) is a limited liability company registered in England and
> Wales with its registered address at YouView TV Ltd, 3rd Floor, 10 Lower
> Thames Street, London, EC3R 6YT. For details see our web site at
> http://www.youview.com
> --
>
> 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
-- 

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] [CMake] Debugging find_package() search behavior?

[David Cole via cmake-developers]

Sorry for the mis-statement. I stand corrected.

However, it is true that there are many find modules with some
differences in approach, and if you are using one, you need to read up
on the individual documentation of that particular find module.
Especially if you need to know how to tell it how to find the exact
one you already know you have...




On Tue, Aug 29, 2017 at 11:49 AM, Brad King <brad.k...@kitware.com> wrote:
> On 08/29/2017 11:33 AM, David Cole wrote:
>> That's correct:
>>
>> find modules do what they want, and most do not pay attention to
>> CMAKE_PREFIX_PATH.
>
> CMAKE_PREFIX_PATH *is* used by find modules.
>
> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
> See the documentation of find_library, find_path, etc. for details.
> Each command searches an appropriate `/` where ``
> is based on the kind of command doing the searching.
>
> -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] [CMake] Debugging find_package() search behavior?

[David Cole via cmake-developers]

That's correct:

find modules do what they want, and most do not pay attention to
CMAKE_PREFIX_PATH.

It's better to use a config file, but when you have to use a find
module, you have to dig in and figure out the right way to use each
one.



On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> I think the discrepancy here might be config vs module find mode. The
> documentation I linked seems to be for config mode only, however I'm
> utilizing the CMake-shipped FindZLIB.cmake module to find this
> particular library. Does this offer no guarantees on how
> CMAKE_PREFIX_PATH is used?
>
> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey
> <rcdailey.li...@gmail.com> wrote:
>> What I'm hoping for is that find_package() follows the rules it
>> documents here:
>> https://cmake.org/cmake/help/v3.6/command/find_package.html
>>
>> Specifically, it states it searches these paths (and that  is
>> treated case-insensitive):
>>
>> /   (W)
>> /(cmake|CMake)/ (W)
>> /*/   (W)
>> /*/(cmake|CMake)/ (W)
>> /(lib/|lib|share)/cmake/*/  (U)
>> /(lib/|lib|share)/*/(U)
>> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>>
>> If this is true, then the 3rd one from the top should be a match,
>> because  is set to:
>>
>> E:/code/frontend/msvc_2015/third_party/installed
>>
>> And  is set to ZLIB in find_package() first argument, so it
>> should be adding that to the end.
>>
>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
>> ("installed") because I have other libraries that get installed in
>> that directory, each with their own directory to contain their
>> installation files. If find_package() is appending  to 
>> like it says it should, it should find each one of them without
>> switching the value of CMAKE_PREFIX_PATH.
>>
>> Am I misunderstanding something?
>>
>>
>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>>
>>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>>> <rcdailey.li...@gmail.com> wrote:
>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>>
>>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>>> drive letters on Windows.
>>>>>
>>>>> Oops, sent too soon.
>>>>>
>>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>>> cross-compiling
>>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>>
>>>>> -Brad
>>>>
>>>> Ok but even if I remove that, find_package() still isn't working..
>>>> --
>>>>
>>>> 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
-- 

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] [CMake] Debugging find_package() search behavior?

[David Cole via cmake-developers]

Is there a ZLIBConfig.cmake file which find_package is searching for?
(i.e. -- somewhere under that directory does that file exist?) On
Windows the case won't matter, but on Linux, a find_package(ZLIB will
expect a case-sensitive match on a ZLIBConfig.cmake file.

If ZLIBConfig.cmake exists, it needs to exist in one of the locations
on that find_package documentation snippet you sent. If it's not
directly in the "zlib" folder, or one of the other folders listed,
then it won't be found. The directory it is in, or something matching
one of those in the list needs to be included in your
CMAKE_PREFIX_PATH.


If that file does not exist, then the CMake FindZLIB.cmake module will
be used in an attempt to find your zlib... And the help for that
speaks of setting a ZLIB_ROOT var if you want to direct it to find a
given zlib. See the "HINTS" section here:

https://cmake.org/cmake/help/v3.6/module/FindZLIB.html#hints


One more hint regarding CMAKE_PREFIX_PATH : despite its name, it is a
**list** of paths, and you can use multiple semi-colon separated
values if necessary. So, if appending "/zlib" works, then you could
always find zlib and all your other stuff too by using two directories
as your CMAKE_PREFIX_PATH value.


HTH,
David C.



On Tue, Aug 29, 2017 at 11:11 AM, Robert Dailey
<rcdailey.li...@gmail.com> wrote:
> What I'm hoping for is that find_package() follows the rules it
> documents here:
> https://cmake.org/cmake/help/v3.6/command/find_package.html
>
> Specifically, it states it searches these paths (and that  is
> treated case-insensitive):
>
> /   (W)
> /(cmake|CMake)/ (W)
> /*/   (W)
> /*/(cmake|CMake)/ (W)
> /(lib/|lib|share)/cmake/*/  (U)
> /(lib/|lib|share)/*/(U)
> /(lib/|lib|share)/*/(cmake|CMake)/  (U)
>
> If this is true, then the 3rd one from the top should be a match,
> because  is set to:
>
> E:/code/frontend/msvc_2015/third_party/installed
>
> And  is set to ZLIB in find_package() first argument, so it
> should be adding that to the end.
>
> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory
> ("installed") because I have other libraries that get installed in
> that directory, each with their own directory to contain their
> installation files. If find_package() is appending  to 
> like it says it should, it should find each one of them without
> switching the value of CMAKE_PREFIX_PATH.
>
> Am I misunderstanding something?
>
>
> On Tue, Aug 29, 2017 at 10:06 AM, David Cole <dlrd...@aol.com> wrote:
>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?
>>
>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
>> <rcdailey.li...@gmail.com> wrote:
>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> wrote:
>>>> On 08/29/2017 10:55 AM, Brad King wrote:
>>>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>>>>>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>>>
>>>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>>>> drive letters on Windows.
>>>>
>>>> Oops, sent too soon.
>>>>
>>>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for 
>>>> cross-compiling
>>>> to re-root paths like `/usr` into some prefix on the host.
>>>>
>>>> -Brad
>>>
>>> Ok but even if I remove that, find_package() still isn't working..
>>> --
>>>
>>> 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
-- 

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] [CMake] Debugging find_package() search behavior?

[David Cole via cmake-developers]

Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH?

On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey
 wrote:
> On Tue, Aug 29, 2017 at 9:56 AM, Brad King  wrote:
>> On 08/29/2017 10:55 AM, Brad King wrote:
>>> On 08/29/2017 10:48 AM, Robert Dailey wrote:
 CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
 CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>>>
>>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
>>> drive letters on Windows.
>>
>> Oops, sent too soon.
>>
>> CMAKE_FIND_ROOT_PATH should not be necessary here.  It's for cross-compiling
>> to re-root paths like `/usr` into some prefix on the host.
>>
>> -Brad
>
> Ok but even if I remove that, find_package() still isn't working..
> --
>
> 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
-- 

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] Future of ccmake and cmake-gui

[David Cole via cmake-developers]

This is great to see CMake continuing to evolve like this!

What's next, a web page CMake UI connected to cmake server instances
on multiple platforms? ;-)



On Wed, Aug 16, 2017 at 6:05 PM, Daniel Pfeifer  wrote:
> On Wed, Aug 16, 2017 at 6:16 PM, Eric Wing  wrote:
>>
>> On 8/15/17, Daniel Pfeifer  wrote:
>> > Hi,
>> >
>> > With !977 merged, it is possible to base ccmake and cmake-gui on top of
>> > the
>> > cmake server.
>> > For demonstration, I copied the contents of the Source/CursesDialog
>> > directory and added a proxy implementation of the classes `cmake` and
>> > `cmState`. The result is 100% compatible with `ccmake`. The same would
>> > be
>> > possible with cmake-gui.
>> >
>> > Shall we proceed in this direction?
>> >
>> > To make the server available everywhere, we should backport the code
>> > from
>> > C++14 to C++11. I think this is limited to replacing `std::make_shared`.
>> >
>> > For cmake-gui, the proxies could use Qt functionality (QProcess,
>> > QJsonDocument, etc.). As a result, cmake-gui would not have any build
>> > dependencies apart from Qt.
>> >
>> > It might be worth considering to move ccmake and cmake-gui to their own
>> > repositories.
>> >
>> > Cheers, Daniel
>> >
>>
>> If this is a new rewrite...
>
>
> It is not. Both ccmake and cmake-gui use the use the `cmake` class as a
> facade to the cmakelib.
> In my prototype I re-implemented the `cmake` class as a client to the
> cmake-server using json-cpp and libuv.
> This allows separating ccmake and cmake-gui from the cmakelib without
> further changes to the rest of the code.
>
> The same client implementation might be used for ccmake and cmake-gui, but
> cmake-gui might as well use Qt facilities instead.
>
>> I am not making a strong push for this, but I want to bring it up to
>> at least get people thinking about this... I am disturbed by the size
>> and complexity of Qt. My past experiences have not been good and I
>> find it a massive chore to get an environment setup (especially on Mac
>> and Windows...and building Qt on Raspberry Pi is a nightmare). And the
>> binary sizes are large. (I do ship CMake to my users and its size with
>> the GUI is non-trivial.)
>>
>> CMake's actual GUI isn't that complex. Have you considered something
>> lighter-weight?
>>
>> As one alternative, there is IUP:
>> http://webserver2.tecgraf.puc-rio.br/iup/
>> (it's from the same university that created Lua...in fact I think one
>> of the original authors of the white paper/project went on to become
>> one of the Lua authors.)
>>
>> IUP differs from Qt in that is is focused on wrapping native GUI
>> widgets (in constrast to Qt which creates its own non-native widgets).
>> Hence, the library is really small since it only depends on each
>> platform's native libraries. The core library is about 1MB. I just
>> ported (rewrote) a simple Qt based app to IUP. The Qt version was
>> almost 40MB. The IUP RAM usage is also many times smaller.
>>
>> It has native backends for Windows, GTK2, GTK3, Motif, Haiku. Because
>> it historically didn't have a Mac OS X backend, most people overlooked
>> it. However...I've been implementing a native Mac OS X backend. It's
>> not finished, but there is a lot implemented and I'm actually shipping
>> a simple app with it this week. Since CMake's GUI usage is also pretty
>> simple, I *think* there might already be enough implemented to do the
>> CMake-GUI...or it's close enough that I probably could finish those
>> needed features.
>>
>> Also, I implemented a CMake build system for IUP.
>>
>> IUP is MIT licensed.
>
>
> Sounds interesting.
>
>> Now IUP only does GUI (which is another reason it stays small), so you
>> will need to fill in the JSON and Process requirements. But there are
>> tons of JSON libraries. Off the top of my head, cJSON is a really
>> fast, tiny, and simple to use JSON library. It's a single C file and
>> header, so you can drop it right in the project. (Also MIT). It also
>> has a CMake build system if you really want it.
>>
>>
>>
>> And a cross-platform create process...those I've seen everywhere and
>> I've actually written my own too. I think Apache Runtime is only
>> measured in hundreds of kilobytes even with all the stuff you don't
>> need.
>> A quick Google search turned up this one C++ (MIT)
>> https://github.com/eidheim/tiny-process-library
>
>
> That would not be necessary. A cache editor build on IUP could use the same
> cmake client implementation as ccmake.
>
>> So IUP + some JSON + some Process should be around 1MB-2MB. This is in
>> contrast to the Qt frameworks I have right now in my CMake bundle for
>> Mac.
>>
>>
>> Anyway, I know this is going to be outside peoples' comfort-zone which
>> is why I'm not going to push hard on it. But in general, I would like
>> something smaller, easier to build, and lighter on system resources
>> (and real native GUIs generally provide a better user experience). So
>> I'm hoping 

Re: [cmake-developers] Java language support regression (compared with 3.7.x and 3.8.x) for 3.9.0

[David Cole via cmake-developers]

Alan, you had said in your original post:

"Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0
source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it
just does not exist."

Try searching for "_CREATE_SHARED_MODULE" instead... it's combined in code with 
the name of the language.

Just a hint about how to further the investigation. I'm curious what the result 
will be, but don't have time right now to dig in on something peripheral to my 
main to do list.


David C.


> On Jul 25, 2017, at 5:07 AM, Eric Noulard  wrote:
> 
> 
> 
> 2017-07-22 0:23 GMT+02:00 Alan W. Irwin :
>> I have built CMake-3.9.0 on my Linux (Debian Jessie) platform using
>> the bootstrap method I have always successfully used for other CMake
>> versions (including 3.7.2).
>> 
>> For a complex project (PLplot) which uses swig_add_module and
>> swig_link_libraries to implement our Java binding, I get the following
>> error message at the end of that CMake-3.9.0 output.
>> 
>> -- Configuring done
>> CMake Error: Error required internal CMake variable not set, cmake may
>> not be built correctly.
>> Missing variable is:
>> CMAKE_Java_CREATE_SHARED_MODULE
>> -- Generating done
>> -- Build files have been written to:
>> /home/software/plplot/HEAD/build_dir
>> 
>> I don't get this error message for CMake-3.7.2.
>> 
>> Using find and xargs -0 grep I have looked in both 3.7.2 and 3.9.0
>> source code for any mention of CMAKE_Java_CREATE_SHARED_MODULE, and it
>> just does not exist.
>> 
>> By the way, I have tried the following simple project.
>> 
>> cmake_minimum_required(VERSION 3.6.2 FATAL_ERROR)
>> project(test_java NONE)
>> enable_language(Java)
>> message(STATUS "CMAKE_Java_CREATE_SHARED_MODULE = 
>> ${CMAKE_Java_CREATE_SHARED_MODULE}")
> 
> I'm curious with that.
> I do currently use UseJava.cmake module
> https://cmake.org/cmake/help/v3.7/module/UseJava.html
> for building some java bits in a globally C++ project.
> 
> I never tried  enable_language(Java)
> what is the status of Java support as a primary language?
> 
> I tried to find informations about that in the doc and mailing list but 
> didn't find much.
> 
> Could someone please point me to the appropriate place concerning this?
> 
> 
> -- 
> Eric
> -- 
> 
> 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
-- 

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] [CMake] CPack install 3rd party shared libraries

[David Cole via cmake-developers]

Very nice example. Does CMake have a place to put examples like VTK
does...? If so, where is it? And if not, it would be super useful to
start one somewhere "official."

However, one word of caution on the example. I know it was targeted at
Linux, and perhaps for a very simple case it's proper, but using an
unconditional "local" for everything in a
gp_resolved_file_type_override would not be something you'd want to do
in general, especially on Windows. You would end up with probably on
the order of a hundred (or maybe nowadays even a few hundred) DLLs
from the Windows system directories inside your bundle. Almost
certainly not what you intended.


Cheers,
David C.



On Wed, Jul 19, 2017 at 9:57 AM, Elvis Stansvik
 wrote:
> 2017-07-19 13:42 GMT+02:00 Roman Wüger :
>> The problem with BundleUtilities which Inder is that it doesn't support 
>> generator expressions.
>>
>> Maybe I do something wrong?
>> But I need to specify the path to the executable (generator expression) and 
>> the paths where to look for dependencies. Right?
>
> You don't need to use a generator to fetch the executable path. You
> will know the path, since you installed the executable with
> install(..) :) I think most people essentially hardcode the executable
> path in their call to fixup_bundle(..).
>
> If you really want to, I think there is a way to use generator
> expressions, and that is to put the fixup_bundle(..) call in a
> separate file (say InstallStuff.cmake.in), and then process that file
> with file(GENERATE OUTPUT ...) [1] to produce InstallStuff.cmake with
> generator expressions evaluated and then use install(SCRIPT
> InstallStuff.cmake). But that's much too complicated IMHO, and I would
> avoid it.
>
> I made a minimal example that links against zlib and also the Boost
> library you mentioned:
>
> cmake_minimum_required(VERSION 2.8)
>
> project(bundletest)
>
> find_package(ZLIB REQUIRED)
> find_package(Boost REQUIRED COMPONENTS filesystem)
>
> add_executable(bundletest main.cpp)
>
> target_include_directories(bundletest PRIVATE ${ZLIB_INCLUDE_DIRS}
> ${Boost_INCLUDE_DIRS})
>
> target_link_libraries(bundletest ${ZLIB_LIBRARIES} ${Boost_LIBRARIES})
>
> install(TARGETS bundletest
> RUNTIME DESTINATION "bin"
> )
>
> install(CODE "
> function(gp_resolved_file_type_override resolved_file type_var)
>set(\${type_var} local PARENT_SCOPE)
> endfunction()
> include(BundleUtilities)
> fixup_bundle(\"\${CMAKE_INSTALL_PREFIX}/bin/bundletest\" \"\" \"\")
> " COMPONENT Runtime)
>
> main.cpp:
>
> #include 
> #include 
> #include 
>
> using namespace boost::filesystem;
>
> int main (int argc, char *argv[]) {
> // Pretend we're using zlib and Boost
> deflateInit(0, 0);
> std::cout << file_size(argv[1]) << std::endl;
> return 0;
> }
>
> The overriding of the gp_resolved_file_type_override was necessary, to
> make it treat all libraries as local (otherwise it skips "system"
> libraries). See the docs for GetPrerequisites.
>
> Building/installing this with
>
> mkdir build
> cd build
> cmake -DCMAKE_INSTALL_PREFIX=~/bundletest_install ..
> make install
>
> produces:
>
> /home/estan/bundletest_install
> /home/estan/bundletest_install/bin
> /home/estan/bundletest_install/bin/bundletest
> /home/estan/bundletest_install/bin/libm.so.6
> /home/estan/bundletest_install/bin/libstdc++.so.6
> /home/estan/bundletest_install/bin/libc.so.6
> /home/estan/bundletest_install/bin/libz.so.1
> /home/estan/bundletest_install/bin/libpthread.so.0
> /home/estan/bundletest_install/bin/libboost_system.so.1.58.0
> /home/estan/bundletest_install/bin/libgcc_s.so.1
> /home/estan/bundletest_install/bin/libboost_filesystem.so.1.58.0
>
> I did the build on Ubuntu, and tested that it also runs in a clean
> Fedora 24 Docker container.
>
> Hope that helps some.
>
> Elvis
>
> [1] https://cmake.org/cmake/help/v3.9/command/file.html
>
>>
>> Please, could you give me a hint?
>>
>> Regards
>> Roman
>>
>>> Am 19.07.2017 um 12:40 schrieb Elvis Stansvik 
>>> :
>>>
>>> 2017-07-19 10:24 GMT+02:00 Roman Wüger :
 Hello,

 I have a project which depends on a self compiled 3rd party project (boost)
 Boost is here only an example, there are other 3rd party libraries too.

 If I call the "install" command on the target, then it would be packaged.
 But how could I add the shared libraries and especially the links for the 
 shared libraries?

 E.g.:
 libboost_filesystem.so -> libboost_filesystem.so.1.48.0
 libboost_filesystem.so.1.48.0

 Thanks in advance
>>>
>>> I think fixup_bundle() from BundleUtilities is what you want [1].
>>>
>>> We're using it to make our Windows and macOS installs standalone, but
>>> (I think) it should work on Linux as well.
>>>
>>> [1] https://cmake.org/cmake/help/v3.8/module/BundleUtilities.html
>>>

 Best Regards
 Roman
 --

 Powered by 

[cmake-developers] Question about ALIAS targets

[David Cole via cmake-developers]

Is there a good reason why this error must be an error?

CMake Error at CMakeLists.txt:23 (add_library):
  add_library cannot create ALIAS target "MyProj::gtest" because target
  "OtherProj::googletest" is IMPORTED.

The line of code is:

add_library(MyProj::gtest ALIAS OtherProj::googletest)

Why is there any restriction on ALIAS targets about what sorts of
targets they may be aliases of?

After my find_package(OtherProj) call, which is a super build which
defines lots of imported targets, I want the target to be named gtest
to match its library name, but OtherProj has named it googletest.

I can brute force this particular one to just be another IMPORTED
target with all the same properties and property values as the
original, but it seems to me this particular case should be allowed
unless there's a fundamental problem I'm not aware of.

Thanks for any explanations


David C.
-- 

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] Debugging issues with enable_language(CSHARP)

[David Cole via cmake-developers]

Have you looked into
https://github.com/Kitware/CMake/blob/master/Modules/CMakeDetermineCSharpCompiler.cmake
?

Send steps to reproduce the problem you're seeing... Maybe somebody
else here has encountered the same thing and worked through it
already.


HTH,
David C.



On Wed, Mar 22, 2017 at 12:33 PM, Wesley Smith  wrote:
> Hi,
> I'm trying to diagnose why enable_language(CSHARP) isn't working for me in
> the RC candidate. I've built CMake from source and am trying to step through
> the code, but am coming up against the fact that this is an enormous project
> and I don't quite know where to look.
>
> The new C# support is something I want to use on an upcoming project, so I'd
> like to help solve any issues with it
>
> Here's where I'm at:
>
>
> * I'm stepping through cmGlobalGenerator.xx in the EnableLanguage function.
> When the only language is CSHARP, I'm erroring out where it attempts to get
> the definition of CMAKE_SHARP_COMPILER
>
> * In CMakeErrr.log, I see:
> The CSharp compiler identification could not be found in
> "C:/Users/wes/Documents/GitHub/add-in/build_/CMakeFiles/3.8.20170317-g45851/CompilerIdCSharp/CompilerIdCSharp.csproj"
>
> When I compile and run this project by hand, I'm seeing
>
> InfoCompiler
> "INFO:compiler[Microsoft Visual Studio]"
> InfoPlatform
> "INFO:platform[Windows]"
> InfoArchitecture
> "INFO:arch[x64]"
> InfoCompilerVersion
> "INFO:compiler_version[2017]"
>
> printed from this code:
>
> static void Main(string[] args)
> {
> // we have to print the lines to make sure
> // the compiler does not optimize them away ...
> System.Console.WriteLine(InfoCompiler);
> System.Console.WriteLine(InfoPlatform);
> System.Console.WriteLine(InfoArchitecture);
> System.Console.WriteLine(InfoCompilerVersion);
> }
>
>
> It all looks good to me.  What I haven't been able to find is where the
> project is compiled and run from within CMake and the console stdout read in
> order to verify the C# compiler settings.
>
>
> thanks,
> wes
>
>
> --
>
> 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
-- 

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] [CMake 0015749]: Make the URL option of ExternalProject_Add to accept lists

[David Cole via cmake-developers]

Looks like you could also use a list of paths if you express them in
"file://..." form. Local files can also be expressed as URLs.


David C.



On Wed, Jul 13, 2016 at 4:18 AM, Schmertmann, Lars
 wrote:
> Hello there,
>
> I try to continue the work from André.
> With the attached patch it is possible to use a list of URLs
> but it is still limited to a single path.
>
> I think for a mix of pathes/URLs we need to move a lot of code
> from ExternalProject.cmake into ExternalProject-download.cmake.
> Maybe it is good to realize this in a new ticket/commit?
>
> Best regards
> Lars Schmertmann
>
>
> --
>
> 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
-- 

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] Patch to only consider build dependencies between files in the source directory

[David Cole via cmake-developers]

Brad's point with "/" or null terminator was that the directory name
**must** be the directory itself, or a sub-directory of the one in
question.

i.e.

if it's "my/src"

then it should either be exactly "my/src" or "my/src/someSubDir" , not
"my/srcSiblingDir"




On Fri, Mar 18, 2016 at 11:52 AM, Attila Krasznahorkay
 wrote:
> Hi Brad,
>
>>> +  // If it's an absolute path, check if it starts with the source
>>> +  // direcotory:
>>> +  return ( ( path.find( SourceDir ) != 0 ) &&
>>> +   ( path.find( BinaryDir ) != 0 ) );
>>
>> Please look at using strncmp and a check that the following character
>> is a nul terminator or '/'.  Otherwise an external location with
>> a common prefix may be mistaken for part of the project.
>
> Not sure what scenario you have in mind here. :-/ std::string::find should 
> only return 0 if the source directory path or binary directory path is what 
> the evaluated path begins with. Why should we worry what the path continues 
> with?
>
> I was wondering about possibly using strncmp, but thought that 
> performance-wise std::string::find should be fine as well here.
>
> I'm not at all against changing the code, I just don't understand yet what 
> setup the current code would not handle correctly.
>
>> Also please add documentation in a
>>
>>  Help/variable/CMAKE_DEPENDS_IN_PROJECT_ONLY.rst
>>
>> file and update Help/manual/cmake-variables.7.rst to reference it.
>
> Will do. Was just not sure where to add this documentation.
>
> Cheers,
> Attila
> --
>
> 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
-- 

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] C# support ready for review

[David Cole via cmake-developers]

Seems to me like C# support should work just fine with other generators: ninja, 
nmake, and UNIX Makefiles included. Especially with mono on Linux/Mac.


David

> On Mar 7, 2016, at 2:12 PM, Brad King  wrote:
> 
>> On 02/25/2016 05:51 AM, Stuermer, Michael  SP/HZA-ZSEP wrote:
>> The part that probably needs most additional work is all the
>> C# detection and configuration part in the module scripts.
> 
> In your branch Modules/CMakeDetermineCSharpCompiler.cmake currently
> has a lot of logic and environment checks for this.  It shouldn't
> need to be that complicated.  Anything requiring deep introspection
> of the system (especially the registry) should be something done
> in the C++ generator implementation and provided to CMake platform
> files as a variable.
> 
> For example, the VS generators always provide msbuild:
> 
> https://cmake.org/cmake/help/v3.5/variable/CMAKE_VS_MSBUILD_COMMAND.html
> 
> For the path to the compiler tool, take a look at
> 
> Modules/CompilerId/VS-10.vcxproj.in
> 
> and use of it by Modules/CMakeDetermineCompilerId.cmake.  That all
> runs while detecting the compiler id using a small test project.
> It has a custom command that searches the PATH in the IDE project
> build environment to print out the path to the compiler.  You should
> create one like this for CSharp too.
> 
> We'll also need to define behavior when CSharp is enabled by projects
> under a non-VS generator.  Other generators should reject any such
> attempt with an error message.
> 
> 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
-- 

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] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[David Cole via cmake-developers]

I agree with Brad, the --timeout command line parameter should only
set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test
TIMEOUT properties should be left as is for this change.

A **new** --timeout-scale with well defined / documented interactions
with the global variable and the test properties would be the best
approach for introducing changes in behavior. Or a **new**
--ignore-timeout-test-property to simply use the global value
everywhere for some use cases.


D



On Thu, Dec 17, 2015 at 12:53 PM, Ben Boeckel  wrote:
> On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
>> On the cmake general list, Brad recently answered my original query on this
>> subject and appears to agree with me that that ctest --timeout
>> option should always have the highest priority, i.e., override any
>> timeout set by the project such as the above TIMEOUT property.
>
> Here's the snippet from Brad's message:
>
>> From the history of that code it looks like --timeout was added with
>> no consideration of its relationship to CTEST_TEST_TIMEOUT.  Some
>> other CTest options in the same scope as CTEST_TEST_TIMEOUT can be
>> overridden by the command line, so I agree that --timeout should
>> override it too.
>
> 
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/54086/focus=54168
>
> which implies that --timeout sets CTEST_TEST_TIMEOUT, but any properties
> would ignore the setting (as they do now).
>
> --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
-- 

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] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[David Cole via cmake-developers]

The principle "most local setting wins" should be followed.

If a script is called without --timeout cmd line param, CTEST_TEST_TIMEOUT 
applies, if set. Otherwise default timeout value.

If a script is called with --timeout cmd line param, then that **is** the 
timeout value, and CTEST_TEST_TIMEOUT should be ignored.

In either case, test property TIMEOUT should win/override to preserve the 
backwards compatibility for the use cases which currently depend on that.
 
Good scripts will wrap their setting of CTEST_TEST_TIMEOUT with an "if(NOT 
DEFINED" anyhow... Same with good projects.


David

> On Dec 17, 2015, at 2:42 PM, Ben Boeckel <ben.boec...@kitware.com> wrote:
> 
>> On Thu, Dec 17, 2015 at 13:54:08 -0500, David Cole wrote:
>> I agree with Brad, the --timeout command line parameter should only
>> set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test
>> TIMEOUT properties should be left as is for this change.
> 
> This behavior also makes sense to me. However, what about script mode
> which sets CTEST_TEST_TIMEOUT itself? Is CTEST_TEST_TIMEOUT readonly if
> --timeout is given?
> 
> --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] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[David Cole via cmake-developers]

Sounds to me like lapack should conditionally set CTEST_TEST_TIMEOUT only if 
it's not DEFINED already. With such code in the project, callers could define 
it on the command line with -D, or directly in a ctest -S script, and the 
passed in vale would "win" since in this case, the project would NOT set its 
default value.

Pretty standard to do "set only if not set" for variables that callers might 
potentially want to override in a ctest script or in a CMakeLists file.

This works with existing recent versions of cmake and ctest just fine... I 
think ctest has supported -D cmd line params since 3.0 or so.


David

> On Dec 17, 2015, at 6:38 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
> 
>> On 2015-12-17 13:54-0500 David Cole wrote:
>> 
>> I agree with Brad, the --timeout command line parameter should only
>> set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test
>> TIMEOUT properties should be left as is for this change.
>> 
>> A **new** --timeout-scale with well defined / documented interactions
>> with the global variable and the test properties would be the best
>> approach for introducing changes in behavior. Or a **new**
>> --ignore-timeout-test-property to simply use the global value
>> everywhere for some use cases.
> 
> This seems like a reasonable approach to me to get these timeout issues
> addressed.
> 
> However, to be clear, here are the consequences for a project like
> lapack where some extrordinary but legitimate timing variations can occur.
> 
> 1. The current advice to such projects would be to rigourously avoid setting 
> either
> CTEST_TEST_TIMEOUT or individual test timeout properties since the user 
> currently
> has no control over those (which illustrates why addressing the above
> issues is important).
> 
> 2. Once the --timeout fix that allows it to override
> CTEST_TEST_TIMEOUT set by the project has become part of a release,
> AND when that version of cmake is the minimum allowed by the project,
> then it will be safe for the project to start using CTEST_TEST_TIMEOUT
> since that value can now be overridden by the user with the --timeout
> option. But the project should still rigourously avoid using
> individual timeout properties until the conditions listed in 3. are
> true.
> 
> 3. Once the implementation of the proposed new --timeout-scale option
> has been implemented and become part of a release, AND when that
> version of cmake is the minimum allowed by the project, then it will
> be safe for such projects to set both CTEST_TEST_TIMEOUT and
> individual timeout properties since the user now has full control
> over all such project timeouts.
> 
> 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); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); 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

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] [CMake] How to set _default_ timeout for the ctest command? (fwd)

[David Cole via cmake-developers]

Thanks, Ben. That was gonna be my 2 cents, too:

If I set a test property to have a 1, 5 or 10 second timeout, then I
want the test to timeout if it takes any longer than that. I do this
on tests which must execute quickly even in a loaded CPU scenario. I
would not want the global timeout to take precedence in this case and
have my performance critical test taking much longer than it's
supposed to, and then pass anyway with no timeout indication.

More use cases to consider.

Although I do agree, a command line specified option should take
precedence over the global variable/property.

(Just like the test's timeout property should take precedence over the
global too: it's more local in scope, and should be preferred unless
there's a **new** mechanism introduced to change the existing
behavior.)


D




On Tue, Dec 15, 2015 at 11:20 AM, Ben Boeckel  wrote:
> On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
>> On the cmake general list, Brad recently answered my original query on this
>> subject and appears to agree with me that that ctest --timeout
>> option should always have the highest priority, i.e., override any
>> timeout set by the project such as the above TIMEOUT property.  If the
>> consensus continues to be that is the desired behaviour it appears
>> some CMake/CTest code changes will be necessary to change to that
>> behaviour.
>
> Hmm. I don't know. Some tests have timeouts set because they either *do*
> take that long or *shouldn't* take as long as the timeout (e.g., those
> that might deadlock).
>
> I think, instead, that --min-timeout and --max-timeout options might be
> better which allow you to say "this machine is slow; tests may take
> longer (max(property, option))" or "this machine is fast, clamp down the
> timeout (min(property, option))". Alternatively, a --timeout-scale
> option to multiply all timeouts in properties might be better.
>
> --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
-- 

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] RFC: CMake precompiled header support and custom compiler based implementation

[David Cole via cmake-developers]

Yes, that looks like it should work. I'll pull your branch and give it a
try sometime in the coming week.

Thanks,
David

On Friday, December 4, 2015, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:

> On Fri, Dec 4, 2015 at 11:32 PM, David Cole <dlrd...@aol.com
> <javascript:;>> wrote:
> > Makes sense.
> >
> > Can I inject my own "#include " into
> > the generated stream, or otherwise inject something into it?
>
> You should be able to do:
>
> target_include_directories(your_target
>   PUBLIC public
>   PRIVATE private
>   )
> target_precompile_headers(your_target
>   PUBLIC
> public_header1.h
> public_header2.h
>   PRIVATE
> private_header1.h
> private_header2.h
>   )
>
> Does that answer your question? Do you think this could solve your
> use-case?
>
> > Specifically, for me, I want to include some, but not ALL VTK headers
> > for a VTK-based project.
>
> I don't see a problem for that.
>
> > Thanks for working on this.
>
> You are welcome. :-)
>
> > Let me know if you want me to be a Visual Studio tester for you.
>
> Yes, please. My main working environment is Linux. I appreciate any
> feedback from different platforms.
>
-- 

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] RFC: CMake precompiled header support and custom compiler based implementation

[David Cole via cmake-developers]

With Visual Studio, you definitely **need** separate pch for each CONFIG.
Every pch is going to include headers which have Debug/Release differences
in them, and it is not safe to mix and match compiler output from separate
configs together.


D


On Friday, December 4, 2015, Daniel Pfeifer  wrote:

> My working branch is here:
> https://github.com/purpleKarrot/CMake/commits/pch
>
> Feel free to comment, evaluate, contribute.
>
> I am nut fully decided regarding these two questions:
> - Do we want to support different pch per CONFIG? I think no, but I
> might be wrong.
> - Do we want to support different pch per LANGUAGE? I first thought
> yes, but I am no longer certain about that.
>
> On Fri, Dec 4, 2015 at 5:12 AM, Taylor Braun-Jones
> > wrote:
> > Perhaps the Paris Climate talks would be good inspiration for tackling
> > this feature. How many pounds of CO2 are emitted each year due to
> > needless header compilation CPU cycles? :-)
> >
> > On Fri, Oct 30, 2015 at 1:48 AM, James Johnston
> > > wrote:
> >>> -Original Message-
> >>
> >>> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org
> ]
> >>
> >>> On Behalf Of Daniel Pfeifer
> >>
> >>> Sent: Wednesday, October 28, 2015 08:57
> >>
> >>> To: Taylor Braun-Jones
> >>
> >>> Cc: CMake Developers
> >>
> >>> Subject: Re: [cmake-developers] RFC: CMake precompiled header support
> >>
> >>> and custom compiler based implementation
> >>
> >>>
> >>
> >>> On Tue, Oct 27, 2015 at 3:53 AM, Taylor Braun-Jones  >>
> >>> jones.org> wrote:
> >>
> >>> > What's the status of this PCH feature? Does it need testers? More
> >>
> >>> > design input? I'd love to see this feature in a future CMake release.
> >>
> >>> > Willing to help.
> >>
> >>>
> >>
> >>> I haven't worked on it for quite some time as I currently don't have a
> >>
> >> project
> >>
> >>> which needs it.
> >>
> >>> But I agree that we should get it into CMake, even if it does not
> >>
> >>> support
> >>
> >> all
> >>
> >>> generators yet.
> >>
> >>> Support for additional generators can be added successively.
> >>
> >>>
> >>
> >>> I will rebase my branch to master on the weekend, ie port it to
> >>
> >>> cmGeneratorTarget.
> >>
> >>> Then you are free to help with review, testing, and additional
> generators.
> >>
> >>>
> >>
> >>> Which generators are the most important for you?
> >>
> >>
> >>
> >> I'd also love to see some progress on PCH support, though I haven't had
> much
> >> time recently... I'd be quite happy to test however with the below
> compilers
> >> and generators - all of which we would use PCH support with:
> >>
> >>
> >>
> >> Generators:
> >>
> >>
> >>
> >> * Ninja
> >>
> >> * Visual Studio 2008 (eventually 2015)
> >>
> >> * Although we're not currently using it, CMake would be pretty broken
> >> without supporting: Unix Makefiles
> >>
> >>
> >>
> >> Compilers:
> >>
> >>
> >>
> >> * Visual C++ 2008 (eventually 2015): both Ninja and VS generators
> >>
> >> * Embarcadero bcc32 compiler: Ninja
> >>
> >> * GCC: Ninja
> >>
> >>
> >>
> >> Best regards,
> >>
> >>
> >>
> >> James Johnston
> >>
> >>
> >> --
> >>
> >> 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
> > --
> >
> > 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
> --
>
> 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: 

Re: [cmake-developers] RFC: CMake precompiled header support and custom compiler based implementation

[David Cole via cmake-developers]

Right, I was talking about the pch-binary.

Why would CMake even need to generate a header file for pre-compiled
headers? Why not just allow the user to say which of his header files
should be the one to use for precompiled headers?

I have a project I work on which is a VS-only non-CMake based project,
where we name the pch input header files as "${libraryName}PCH.h" and
anything we want included in the pch-binary we can just add to that
file.

Personally, I would prefer to have a manually edited file as the input
to precompiled header so I can add whatever I want in there.

What would be in the contents of the generated header? How do you know
how much or how little is reasonable to put in there? Seems like a
per-library / per-project sort of decision.


D



On Fri, Dec 4, 2015 at 12:26 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
>> On Friday, December 4, 2015, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
>>>
>>> My working branch is here:
>>> https://github.com/purpleKarrot/CMake/commits/pch
>>>
>>> Feel free to comment, evaluate, contribute.
>>>
>>> I am nut fully decided regarding these two questions:
>>> - Do we want to support different pch per CONFIG? I think no, but I
>>> might be wrong.
>>> - Do we want to support different pch per LANGUAGE? I first thought
>>> yes, but I am no longer certain about that.
>
> On Fri, Dec 4, 2015 at 2:42 PM, David Cole <dlrd...@aol.com> wrote:
>> With Visual Studio, you definitely **need** separate pch for each CONFIG.
>> Every pch is going to include headers which have Debug/Release differences
>> in them, and it is not safe to mix and match compiler output from separate
>> configs together.
>
> Maybe we are confusing two things here.
>
> Visual Studio compiles a pch-binary for each configuration. That
> pch-binary is probably incompatible with other configurations.
> In my current implementation, the header file that is used to compile
> the pch-binary is generated by CMake, using information provided by
> the user.
>
> This approach is very powerful, as it supports usage requirements. See
> here for an example:
> You can see here:
> https://github.com/purpleKarrot/CMake/blob/e441eac5b16fd245e6aa014867d43d53c18b6d4d/Tests/PrecompileHeaders/CMakeLists.txt
>
> My question actually boils down to whether CMake should
> (a) generate a header file for each configuration/language, or
> (b) generate a **single** header file which is then precompiled for
> all configurations/languages.
>
> Both approaches are possible, because we can use #ifdef __cplusplus etc.
>
> More importantly: Do we want the user to
> (c) tell CMake about different headers-to-be-precompiled per
> config/language so CMake can write the appropriate #ifdefs into the
> generated file, or
> (d) put #ifdefs into the provided file so that CMake can #include it
> in the generated file without any additional logic?
>
> Again both approaches are technically possible. It is not about what
> we **need**, but what we **want**. And there, I am undecided.
-- 

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] RFC: CMake precompiled header support and custom compiler based implementation

[David Cole via cmake-developers]

Makes sense.

Can I inject my own "#include " into
the generated stream, or otherwise inject something into it?

Specifically, for me, I want to include some, but not ALL VTK headers
for a VTK-based project.

Thanks for working on this.

Let me know if you want me to be a Visual Studio tester for you.


D



On Fri, Dec 4, 2015 at 5:28 PM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
> On Fri, Dec 4, 2015 at 9:19 PM, David Cole <dlrd...@aol.com> wrote:
>> Right, I was talking about the pch-binary.
>>
>> Why would CMake even need to generate a header file for pre-compiled
>> headers? Why not just allow the user to say which of his header files
>> should be the one to use for precompiled headers?
>
> Generating a header file is necessary for two reasons:
>
> 1. In GCC, the compiled pch-binary has to be located in the same
> directory as the pch-source header. For out-of-source-builds, we
> certainly do not want to clutter the source directory, so we need a
> header file inside the binary directory. We could create a copy
> (fragile), a symlink (not portable), or a forward-#include
> (preferred).
>
> 2. There can be only one pch per target. See below.
>
>> I have a project I work on which is a VS-only non-CMake based project,
>> where we name the pch input header files as "${libraryName}PCH.h" and
>> anything we want included in the pch-binary we can just add to that
>> file.
>>
>> Personally, I would prefer to have a manually edited file as the input
>> to precompiled header so I can add whatever I want in there.
>
> That is perfectly reasonable. This is also the reason why I think the
> config/language specific differences should **not** be handled by
> CMake, but by the user.
>
>> What would be in the contents of the generated header? How do you know
>> how much or how little is reasonable to put in there? Seems like a
>> per-library / per-project sort of decision.
>
> If you look at the example I referred to, there is a library `foo`
> with a pch `foo.h` as a usage requirement. There is also an interface
> library `bar` with a pch `bar.h` as a usage requirement. Then there is
> an executable `foobar` which links against both `foo` and bar`. So the
> generated pch-source for the `foobar` target will contain:
>
> 
> /* This file is generated by CMake */
> #include 
> #include 
> 
>
> Making sense?
-- 

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] Fwd: Cmake stucks

[David Cole via cmake-developers]

What OS? What version of CMake? What version of VTK? Did you download
CMake, and if so, from where? Or did you build CMake yourself?



On Tue, Nov 24, 2015 at 7:27 AM, Constantinus Spanakis
 wrote:
> Hello, i tried to configure VTK using Cmake, but  every time it stucks
> while checking on the signedness of char and it doesn't move forward.
> What could be the problem?
> --
>
> 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
-- 

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] Specifying a VS installation path explicitly

[David Cole via cmake-developers]

A simple source tree grep for "HKEY" (or even just "HK") will point you to
all the places CMake has registry key references in its source code...



On Tue, Oct 27, 2015 at 10:38 AM, Johannes Asal 
wrote:

> If it was actually using registry entries only for locating the VS
> installations it would be perfectly fine with me. But my observations
> indicate that it depends on environment variables as well. Could you point
> me to where that logic is implemented in the source code or the CMake
> modules?
>
> Mit freundlichen Grüßen / Best regards
>
> Johannes Asal
> Entwicklungsingenieur Software  |   Identification & Measuring Research &
> Development
>
>
>
> SICK AG  |  Nimburger Str. 11  |  79276 Reute  |  Germany
> Phone +49 7641 469-1460  |  johannes.a...@sick.de  |  http://www.sick.de
>
>
>
> SICK AG  |   Sitz: Waldkirch i. Br.  |   Handelsregister: Freiburg i. Br.
> HRB 280355
> Vorstand: Dr. Robert Bauer (Vorsitzender)  |  Reinhard Bösl  |  Dr. Mats
> Gökstorp  |  Dr. Martin Krämer  |  Markus Vatter
> Aufsichtsrat: Gisela Sick (Ehrenvorsitzende)  |  Klaus M. Bukenberger
> (Vorsitzender)
> --
>
> 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
>
-- 

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] generator expression for path slash conversion

[David Cole via cmake-developers]

Unfortunately, "pushd" is an inappropriate command to use when the
argument is quoted. It works just fine with "/" characters if the
argument is quoted...

For example:

C:\Users\davidcole>pushd C:\Windows\System32

C:\Windows\System32>pushd C:/dev
The syntax of the command is incorrect.

C:\Windows\System32>pushd "C:/dev"

C:\dev>

It would be better to use a test command that **actually** fails when
a "/" path is a quoted entity


HTH,
David C.




On Thu, Sep 24, 2015 at 9:05 AM, Kislinskiy, Stefan
 wrote:
> I factored out the code from cmOutputConverter::ConvertToOutputFormat() into 
> another helper method called ConvertDirectorySeparatorsForShell(), changed 
> the SHELL_PATH genex to accept only absolute paths, and changed its 
> documentation accordingly. I also added a BadSHELL_PATH test to the 
> RunCMake/GeneratorExpression tests, that use the SHELL_PATH genex with an 
> empty parameter as well as a relative path. I also fixed the TEST/CTEST typo 
> you discovered yesterday.
>
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com]
> Sent: Mittwoch, 23. September 2015 16:57
> To: Kislinskiy, Stefan
> Cc: cmake-developers@cmake.org
> Subject: Re: [cmake-developers] generator expression for path slash conversion
>
> On 09/23/2015 10:45 AM, Kislinskiy, Stefan wrote:
>> I see. I would suggest that I add another output flag to
>> cmOutputConverter like SHELL_NO_ESCAPE then. If this flag is passed to
>> ConvertToOutputFormat() instead of SHELL, the call of
>> EscapeForShell() will be circumvented. This way there wouldn't be code
>> duplication and we would still cover the MSYS case (drive letter
>> conversion).
>
> The conversion code in question is about 10 lines and could be factored out 
> into another helper method.  Then the genex impl could just use the helper 
> directly.
>
>> Isn't it possible to specify parameters for generator expressions?
>
> Yes.
>
>> How about something like $?
>
> Neat idea.  However, for now I'd rather not try to predict the use cases for 
> which such parameters will be needed.  Instead we should just make sure the 
> interface leaves room for future extension.  Since "," is allowed in paths we 
> cannot simply disallow it or blindly use it as a separator.  Therefore we 
> should have the actual path always be the last parameter.
>
> For now I think you can just require (with an error) that the value given to 
> SHELL_PATH as input must be an absolute path (cmSystemTools::FileIsFullPath). 
>  Then in the future we could recognize things like 
> $ without ambiguity.  Please include test cases 
> for errors on relative paths (see Tests/RunCMake/GeneratorExpression).
>
> 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
-- 

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] Listing all targets

[David Cole via cmake-developers]

Finally getting back to this, hopefully can push to next this week,
and have this completed in time for the upcoming 3.4 release.

I have three questions before attempting my first merge-to-next for testing:

(1) I see how I can easily move "COMPONENTS" from
cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty
because I can access the global generator from cmState as well... To
move "VARIABLES" and "MACROS," though, I need access to the correct
cmMakefile in which the cmGetCMakePropertyCommand is running. Do I
need to pass the cmMakefile instance as a new parameter to
cmState::GetGlobalProperty, or is the correct Makefile instance
already available from the context of the cmState? (If so, it's
non-obvious to me from code analysis...) Steve, Brad? Any input on
this question?

(2) I will update the documentation of get_cmake_property to say these
are all also available via get_property(GLOBAL ... That's the correct
intent, right? All calls to get_cmake_property should have exactly the
same content as a corresponding call to get_property(GLOBAL?

(3) Is anyone concerned about adding a global property with the
somewhat generic name "TARGETS" ? Do we care if any projects out there
are already doing a set_property(GLOBAL with the name "TARGETS"? The
downside of a project doing so would be that when they try to read the
value back with get_property, CMake's implementation will overwrite
their set values with the list of all available CMake targets, which
may be different than what the project had set into the property.


Thanks for any feedback,
David C.




On Mon, Jul 20, 2015 at 9:30 AM, Brad King <brad.k...@kitware.com> wrote:
> On 07/17/2015 06:05 PM, David Cole via cmake-developers wrote:
>> Attached is a patch file of my first attempt. I can iterate some more
>> on this (better testing, add docs, clarify existing docs, address
>> anybody's comments, submit to stage) next week. Attached now in case
>> anybody wants to try it out over the weekend.
> [snip]
>>> I think the see also is relevant because it points to another way to
>>> get to a whole different set of "properties". Perhaps what they're
>>> looking for when they stumble upon get_cmake_property is actually
>>> target properties, which are only accessible via get_property.
>
> get_cmake_property is get_property with the GLOBAL scope, except that
> it looks like the special VARIABLES, MACROS, and COMPONENTS properties
> are hard-coded into get_cmake_property incorrectly.
>
> This should all be moved over to cmState::GetGlobalProperty and the
> new TARGETS property added there.  That method already has special
> handling for a few other properties too.
>
> Also the documentation of get_cmake_property should be updated to
> mention "global" properties.
>
> -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
-- 

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] Making kwsys a proper library

[David Cole via cmake-developers]

Honestly, KWSys has always seemed like a boost-avoidance mechanism
from an outsider's perspective. Perhaps it should be replaced with
boost equivalents in projects that need to be packaged for Fedora.

I assume all the boost libraries are already packaged/available.


Fuel for the fire, ;-)
D



On Fri, Aug 21, 2015 at 9:27 AM, Brad King brad.k...@kitware.com wrote:
 On 08/20/2015 10:19 PM, Orion Poplawski wrote:
 The consensus of the FPC is that the current situation with KWSys is
 very undesirable.  While this approach may have been reasonable years
 ago with few consumers, it does not seem acceptable at this point.

 FWIW, the origin of this is the following:  Many, many projects have
 their own custom code for many of the things KWSys is doing, but they
 may not organize the implementations into a distinguishable library.
 This does not seem to be a problem for packaging these projects even
 though they could be using third-party libraries instead.

 We have several projects that all want some of these things as details
 of their implementation but we do not want to maintain a first-class
 library for them.  We could have had divergent implementations in
 each project like so many other unrelated projects do, but instead we
 decided to build infrastructure to share the common components of the
 source tree.  This gives our projects the benefits of common, well-
 tested infrastructure without the cost of maintaining a public-facing
 library for them.  If these implementations were not shared under the
 common KWSys banner then no one would have noticed that the projects
 appear to bundle a library.  How is this worse than other projects
 that do not share code at all?

 Yes, several components of KWSys appear to re-implement functionality
 that is now available in better third-party libraries.  However, much
 of it was added to our projects before those third-party libraries
 existed.  Things like the RegularExpression component came from other
 third-parties at the time who were also not providing first-class
 libraries for them.  Now they are kept in KWSys as a way to share the
 implementations among our projects at the source level.

 Any and all efforts by the KWSys maintainers to split out KWSys into
 proper libraries and perhaps pull out code that is only use by a single
 project into that project would be greatly appreciated.

 Some components of KWSys are present for historical reasons and
 can be factored out or removed now.  This will be a worthwhile
 cleanup regardless of the above discussion.

 be greatly appreciated if KWSys using projects would include in their
 tarballs only those components that they actually used.

 Prior to CastXML, KWSys has only been included in projects that are
 much, much larger than itself and use most of its components so its
 size has not stood out before.  I've now reduced the KWSys sources
 inside CastXML to the minimum it needs.  Further discussion on the
 CastXML side would be better held on its own mailing list.

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

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] ExternalProject: Use native paths as substitute for directory tokens

[David Cole via cmake-developers]

It's exactly what I am concerned about:

You're asking to change the behavior of something for EVERYONE to
solve a problem which you have encountered. If you change it the way
you have proposed, you will cause problems for others. It has worked
the way it is now since ExternalProject_Add was introduced in CMake
2.8. Changing it unconditionally the way you propose is simply not
feasible for backwards compatibility.

I think commands that take native paths ought NOT to use the *_DIR
replacement values, and instead, ought to pass in variables that
contain the native paths in the first place.


David C.



On Thu, Aug 20, 2015 at 2:58 PM, James Johnston
johnstonj.pub...@codenest.com wrote:
 Hi,

 Funny you are mailing the list about this, since I just ran into this same 
 issue today building something totally different from Boost...  In this case 
 it's a build tool that thinks the /U in C:/Users is a new command line 
 argument, that isn't recognized - and then the subsequent s also ends up 
 unrecognized... and it all fails...  And it has nothing to do with the 
 working directory, so _Add_Step(WORKING_DIRECTORY) isn't a possible 
 workaround for me.

 I think the issue with globally making this change to the existing tokens is 
 that there could be some external tool/program that is EXPECTING to get CMake 
 paths, not native paths.  Who knows?  I am guessing that is what David Cole 
 was concerned about.

 Maybe the right answer is to introduce some NEW tokens while leaving the 
 behavior of the old ones unchanged.  E.g. BINARY_DIR_NATIVE etc.  It would 
 be good if the patch updates the documentation of ExternalProject and clearly 
 states the path format of BINARY_DIR vs BINARY_DIR_NATIVE.  Then the user 
 can pick whichever one suits them best, depending on the tool being invoked.

 Furthermore, sometimes BINARY_DIR_NATIVE still needs to be replaced with a 
 CMake path, not native path.  For example, if the token is being found in a 
 property like WORKING_DIRECTORY that eventually gets passed to 
 add_custom_command(WORKING_DIRECTORY) then I'm guessing still has to be a 
 CMake path.  I am guessing this is what David Cole was also concerned about.

 I still think your original method of building Boost is a bit unusual and 
 would be better served by _Add_Step with a custom working directory - because 
 that's the publicly documented/standard way of changing the working 
 directory, but that is up to you.  :)

 Best regards,

 James Johnston


  On Thu, 20 Aug 2015 14:37:08 +  Stefan Kislinskiy 
 s.kislins...@dkfz-heidelberg.de wrote 

   Hi,
  
   thank you for our suggestions. I am aware that I can solve my example 
 differently and that it might look not directly connected the proposal, but 
 well, it is an example just to show a single case and why it matters. :) I 
 did not want to discuss the example itself. Working around here would just 
 resolve a symptom.
  
   My point is the overall problem that would persist: A big part of 
 ExternalProject is to issue commands for predefined and custom steps. Those 
 commands are supposed to be executed by the shell/command line. According to 
 the documentation and the source code of ExternalProject, directory tokens 
 are mainly supposed to be replaced in commands. It is my understanding, that 
 it is a bug, if CMake isn't able to assemble these commands correctly. This 
 would include usage of the correct path style of the OS for shell/command 
 line commands. As directory tokens are replaced internally right before a 
 shell/command line command is assembled, I can't see why this would be kind 
 of API-breaking. You cannot interfere in your CMake code with these 
 internal replacements.
  
   Therefore I would still prefer my solution as it is pretty simple without 
 adding even more features to ExternalProject and in my opinion without 
 breaking code in the wild. It is a true bug fix instead of a feature request 
 for working directories, which is a different topic that just coincidentally 
 arised because of my specific example I guess. The features you described 
 wouldn't fix the actual bug.
  
   As you were not sure if my approach would even fix my problems: It does of 
 course and this is what I am currently doing and what I tested extensively 
 before creating the patch. :) Regarding your quote from the 
 add_custom_command documentation I can tell you that this is how things are 
 currently done in ExternalProject and always were as far as I know, for 
 example (from ExternalProject.cmake):
  
 add_custom_command(
   OUTPUT ${stamp_file}
   BYPRODUCTS ${byproducts}
   COMMENT ${comment}
   COMMAND ${command}
   COMMAND ${touch}
   DEPENDS ${depends}
   WORKING_DIRECTORY ${work_dir}
   VERBATIM
   )
  
   Best regards,
   Stefan
  
  
   -Original Message-
   From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On 
 Behalf Of James Johnston
   Sent: Donnerstag, 20

Re: [cmake-developers] ExternalProject: Use native paths as substitute for directory tokens

[David Cole via cmake-developers]

But some existing replacements require forward slashes, we can't just to
native path everything blindly. I think you will have to special case the
bits which do need native paths.


On Wednesday, August 19, 2015, Kislinskiy, Stefan 
s.kislins...@dkfz-heidelberg.de wrote:

 Hi,

 I would like to contribute a fix regarding directory tokens (e.g.
 SOURCE_DIR) in the ExternalProject module. These tokens are replaced by
 their matching target property value _EP_${dir}. However, the path
 substitutes are not converted to native path style which makes it
 impossible to use directory tokens in some Windows commands like pushd, as
 these commands are not able to handle forward slashes. I attached a tiny
 patch which simply calls file(TO_NATIVE_PATH) before replacing directory
 tokens.

 Best regards,
 Stefan Kislinskiy
-- 

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] Listing all targets

[David Cole via cmake-developers]

Thanks for the comments. I'll incorporate these into my next iteration...

On Mon, Jul 20, 2015 at 9:30 AM, Brad King brad.k...@kitware.com wrote:
 On 07/17/2015 06:05 PM, David Cole via cmake-developers wrote:
 Attached is a patch file of my first attempt. I can iterate some more
 on this (better testing, add docs, clarify existing docs, address
 anybody's comments, submit to stage) next week. Attached now in case
 anybody wants to try it out over the weekend.
 [snip]
 I think the see also is relevant because it points to another way to
 get to a whole different set of properties. Perhaps what they're
 looking for when they stumble upon get_cmake_property is actually
 target properties, which are only accessible via get_property.

 get_cmake_property is get_property with the GLOBAL scope, except that
 it looks like the special VARIABLES, MACROS, and COMPONENTS properties
 are hard-coded into get_cmake_property incorrectly.

 This should all be moved over to cmState::GetGlobalProperty and the
 new TARGETS property added there.  That method already has special
 handling for a few other properties too.

 Also the documentation of get_cmake_property should be updated to
 mention global properties.

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

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] Listing all targets (was: Wrapping functions in CMake)

[David Cole via cmake-developers]

You're welcome. The key to using it effectively, of course, is using it at
the very bottom of the top level CMakeLists.txt file. It can only report on
the targets defined so far, so if you put it in the middle somewhere,
targets may be defined after you use it, and you'll miss them...


D


On Saturday, July 18, 2015, Clifford Yapp cliffy...@gmail.com wrote:

 On Fri, Jul 17, 2015 at 6:05 PM, David Cole dlrd...@aol.com
 javascript:; wrote:
  Attached is a patch file of my first attempt. I can iterate some more
  on this (better testing, add docs, clarify existing docs, address
  anybody's comments, submit to stage) next week. Attached now in case
  anybody wants to try it out over the weekend.

 David,

 Awesome - thank you for doing that! (Way faster than I would have been
 able to set it up).

 It may be Monday before I can put it through it's paces, but I'll
 definitely give this a go and also see if I can combine it with the
 SOURCES target property Brad pointed out to kill two problems with one
 patch.

 I'll try to get at figuring out how to set up GLOBAL properties for
 collecting various types of message outputs and prepare a patch for
 that on Monday as well, unless someone else gets to it sooner.

 Cheers,
 CY

-- 

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] Listing all targets (was: Wrapping functions in CMake)

[David Cole via cmake-developers]

Are you saying there should be a named GLOBAL property with this
information in it...?

It seems like more of a fit to get_cmake_property.

On Fri, Jul 17, 2015 at 10:14 AM, Ben Boeckel ben.boec...@kitware.com wrote:
 On Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote:
 This would best be added as a TARGETS variant of the existing
 http://www.cmake.org/cmake/help/v3.3/command/get_cmake_property.html
 command.

 (In my opinion...)

 The get_property command would also need to handle it. I don't know if
 it hooks into the more specific commands' implementations though.
 Doesn't seem like it from a cursory reading though.

 --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] Listing all targets (was: Wrapping functions in CMake)

[David Cole via cmake-developers]

I think the see also is relevant because it points to another way to
get to a whole different set of properties. Perhaps what they're
looking for when they stumble upon get_cmake_property is actually
target properties, which are only accessible via get_property.

While it's relevant, and I think it should remain, I do think it could
use some clarification.

I'll take a stab at this, and clarify the docs, too, unless somebody
else chimes in and tells me wait! I'm doing it already

:-)


Cheers,
David C.


On Fri, Jul 17, 2015 at 2:55 PM, Ben Boeckel ben.boec...@kitware.com wrote:
 On Fri, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote:
 get_cmake_property is more like strictly well-pre-defined, read only
 (ish), built-into CMake properties. Note there is no
 set_cmake_property... What docs are you looking at that you think have
 a bug...?

 Help/command/get_cmake_property:

 get_cmake_property
 --

 Get a property of the CMake instance.

 ::

   get_cmake_property(VAR property)

   Get a property from the CMake instance.  The value of the property is
   stored in the variable VAR.  If the property is not found, VAR will be
   set to NOTFOUND.  Some supported properties include: VARIABLES,
   CACHE_VARIABLES, COMMANDS, MACROS, and COMPONENTS.

   See also the more general get_property() command.

 `get_property` has no way (that I see) to ask for the same properties.
 The whole command docs could use a revamp too (while TARGETS is being
 implemented to avoid conflicts?).

 --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] Listing all targets (was: Wrapping functions in CMake)

[David Cole via cmake-developers]

get_cmake_property is more like strictly well-pre-defined, read only
(ish), built-into CMake properties. Note there is no
set_cmake_property... What docs are you looking at that you think have
a bug...?

To implement TARGETS for get_cmake_property, I would look to see what
logic is used by if(TARGET and use the same list it uses as the
value returned here.

Should I work on a patch/branch, or is somebody here already working on it?


D


On Fri, Jul 17, 2015 at 1:54 PM, Ben Boeckel ben.boec...@kitware.com wrote:
 On Fri, Jul 17, 2015 at 12:18:18 -0400, David Cole wrote:
 Are you saying there should be a named GLOBAL property with this
 information in it...?

 It seems like more of a fit to get_cmake_property.

 Indeed. It seems there is no overlap between `get_property` and
 `get_cmake_property`. Which means the docs have a bug.

 --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] Listing all targets (was: Wrapping functions in CMake)

[David Cole via cmake-developers]

Attached is a patch file of my first attempt. I can iterate some more
on this (better testing, add docs, clarify existing docs, address
anybody's comments, submit to stage) next week. Attached now in case
anybody wants to try it out over the weekend.


Cheers,
David C.


On Fri, Jul 17, 2015 at 3:03 PM, David Cole dlrd...@aol.com wrote:
 I think the see also is relevant because it points to another way to
 get to a whole different set of properties. Perhaps what they're
 looking for when they stumble upon get_cmake_property is actually
 target properties, which are only accessible via get_property.

 While it's relevant, and I think it should remain, I do think it could
 use some clarification.

 I'll take a stab at this, and clarify the docs, too, unless somebody
 else chimes in and tells me wait! I'm doing it already

 :-)


 Cheers,
 David C.


 On Fri, Jul 17, 2015 at 2:55 PM, Ben Boeckel ben.boec...@kitware.com wrote:
 On Fri, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote:
 get_cmake_property is more like strictly well-pre-defined, read only
 (ish), built-into CMake properties. Note there is no
 set_cmake_property... What docs are you looking at that you think have
 a bug...?

 Help/command/get_cmake_property:

 get_cmake_property
 --

 Get a property of the CMake instance.

 ::

   get_cmake_property(VAR property)

   Get a property from the CMake instance.  The value of the property is
   stored in the variable VAR.  If the property is not found, VAR will be
   set to NOTFOUND.  Some supported properties include: VARIABLES,
   CACHE_VARIABLES, COMMANDS, MACROS, and COMPONENTS.

   See also the more general get_property() command.

 `get_property` has no way (that I see) to ask for the same properties.
 The whole command docs could use a revamp too (while TARGETS is being
 implemented to avoid conflicts?).

 --Ben


0001-CMake-Add-TARGETS-to-get_cmake_property.patch
Description: Binary data
-- 

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] Listing all targets (was: Wrapping functions in CMake)

[David Cole via cmake-developers]

This would best be added as a TARGETS variant of the existing
http://www.cmake.org/cmake/help/v3.3/command/get_cmake_property.html
command.

(In my opinion...)


David C.


On Thu, Jul 16, 2015 at 11:42 AM, Clifford Yapp cliffy...@gmail.com wrote:
 On Wed, Jul 15, 2015 at 9:10 AM, Brad King brad.k...@kitware.com wrote:
 On 07/10/2015 03:42 PM, Clifford Yapp wrote:
 On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp cliffy...@gmail.com wrote:

 2.  Provide similar lists of all defined targets for the various types
 (e.g. CMAKE_EXECUTABLE_TARGETS, CMAKE_LIBRARY_TARGETS,
 CMAKE_CUSTOM_TARGETS).

 Looking into the CMake sources, it seems like this information is
 stored already in the global target map - what would be the correct
 way to expose that information in variables in CMake script space?

 We shouldn't need separate lists for each because one can check
 the TYPE target property given the target name.

 Ah, good point.

 The list of globally-scoped (non-imported) targets could be made available
 through a (read-only) global property whose implementation
 computes the list on the fly.

 Sounds workable - are there any pre-existing properties like that that
 can serve as a guide for implementation?

 Thanks,
 CY
 --

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

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] cmake.exe parameters and system command line length limit

[David Cole via cmake-developers]

Correct -- it's typically used as an **initial** cache only, in a
clean build tree.

Actually, I'm not sure what happens on subsequent (2nd and later)
runs... It may be that the cache has precedence, and the -C file has
no effect on subsequent runs unless you use FORCE in it... But I'm
uncertain. I'd have to do some code analysis or experimentation to
figure it out.


D



On Tue, Jul 14, 2015 at 9:34 AM, Robert Goulet
robert.gou...@autodesk.com wrote:
 Ah ok this means the -C option is in addition to the cmake cache, and not 
 replace it?

 -Original Message-
 From: David Cole [mailto:dlrd...@aol.com]
 Sent: Monday, July 13, 2015 3:42 PM
 To: Robert Goulet
 Cc: David Cole; cmake-developers@cmake.org
 Subject: Re: [cmake-developers] cmake.exe parameters and system command line 
 length limit

 You don't. It's just another way to specify the command line arguments, but 
 as a single command line argument instead of dozens or hundreds.

 It's a mechanism for you to avoid the command line length limit.
 Wasn't that your question...?


 On Mon, Jul 13, 2015 at 2:01 PM, Robert Goulet robert.gou...@autodesk.com 
 wrote:
 Hi David,

 That option looks interesting. How do we populate it with the other CMake 
 cache values that are originally set by CMake and not by our command line 
 options?

 Thanks.

 -Original Message-
 From: David Cole [mailto:dlrd...@aol.com]
 Sent: Monday, July 13, 2015 1:56 PM
 To: Robert Goulet
 Cc: cmake-developers@cmake.org
 Subject: Re: [cmake-developers] cmake.exe parameters and system
 command line length limit

 You could use the -C command line option to pass in the name of a file 
 containing initial cache values. See the -C initial-cache section at the 
 top of this documentation section:

 http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#options

 The format of the file is just a bunch of set(... CACHE ...) commands.
 Read the doc paragraph carefully, and give it a try. Maybe somebody else can 
 point to a valid example of a live -C file being used out there on the 
 Internet.


 HTH,
 David C.



 On Mon, Jul 13, 2015 at 1:44 PM, Robert Goulet robert.gou...@autodesk.com 
 wrote:
 Hi all,



 We use a custom script to handle which parameters we set to cmake.exe
 on Windows. It sets CMake values based on the options provided to
 this script, using the -D cmake parameter. This works well, but
 recently we’ve reached the limit on how many characters we can set to
 a single system command line (cmd.exe), because our number of options is 
 growing.



 Is there a work-around for this using CMake, or perhaps feed CMake
 parameters from a file rather than from command-line parameters? i.e.
 “cmake.exe  params.txt” ?



 Thanks!


 --

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

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] cmake.exe parameters and system command line length limit

[David Cole via cmake-developers]

You don't. It's just another way to specify the command line
arguments, but as a single command line argument instead of dozens or
hundreds.

It's a mechanism for you to avoid the command line length limit.
Wasn't that your question...?


On Mon, Jul 13, 2015 at 2:01 PM, Robert Goulet
robert.gou...@autodesk.com wrote:
 Hi David,

 That option looks interesting. How do we populate it with the other CMake 
 cache values that are originally set by CMake and not by our command line 
 options?

 Thanks.

 -Original Message-
 From: David Cole [mailto:dlrd...@aol.com]
 Sent: Monday, July 13, 2015 1:56 PM
 To: Robert Goulet
 Cc: cmake-developers@cmake.org
 Subject: Re: [cmake-developers] cmake.exe parameters and system command line 
 length limit

 You could use the -C command line option to pass in the name of a file 
 containing initial cache values. See the -C initial-cache section at the 
 top of this documentation section:

 http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#options

 The format of the file is just a bunch of set(... CACHE ...) commands.
 Read the doc paragraph carefully, and give it a try. Maybe somebody else can 
 point to a valid example of a live -C file being used out there on the 
 Internet.


 HTH,
 David C.



 On Mon, Jul 13, 2015 at 1:44 PM, Robert Goulet robert.gou...@autodesk.com 
 wrote:
 Hi all,



 We use a custom script to handle which parameters we set to cmake.exe
 on Windows. It sets CMake values based on the options provided to this
 script, using the -D cmake parameter. This works well, but recently
 we’ve reached the limit on how many characters we can set to a single
 system command line (cmd.exe), because our number of options is growing.



 Is there a work-around for this using CMake, or perhaps feed CMake
 parameters from a file rather than from command-line parameters? i.e.
 “cmake.exe  params.txt” ?



 Thanks!


 --

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

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] cmake.exe parameters and system command line length limit

[David Cole via cmake-developers]

You could use the -C command line option to pass in the name of a file
containing initial cache values. See the -C initial-cache section
at the top of this documentation section:

http://www.cmake.org/cmake/help/v3.3/manual/cmake.1.html#options

The format of the file is just a bunch of set(... CACHE ...) commands.
Read the doc paragraph carefully, and give it a try. Maybe somebody
else can point to a valid example of a live -C file being used out
there on the Internet.


HTH,
David C.



On Mon, Jul 13, 2015 at 1:44 PM, Robert Goulet
robert.gou...@autodesk.com wrote:
 Hi all,



 We use a custom script to handle which parameters we set to cmake.exe on
 Windows. It sets CMake values based on the options provided to this script,
 using the -D cmake parameter. This works well, but recently we’ve reached
 the limit on how many characters we can set to a single system command line
 (cmd.exe), because our number of options is growing.



 Is there a work-around for this using CMake, or perhaps feed CMake
 parameters from a file rather than from command-line parameters? i.e.
 “cmake.exe  params.txt” ?



 Thanks!


 --

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

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] A policy for Policies

[David Cole via cmake-developers]

Interesting. So, sort of, but not really. At least not explicitly.

I'm still interested in seeing an example commit (even if it's only
theoretical and will never actually be merged in) whose explicit
purpose is removing the OLD behavior of a single policy. (Is there
such a commit which removed the OLD behavior of CMP0010, or is it too
entwined in the parser improvement commits from the 3.1 release cycle
as to be easily identifiable as a concise diff?)


Weird are the things interesting to geeks, right?

Thx,
David C.



On Wed, Jul 8, 2015 at 10:34 AM, Ben Boeckel ben.boec...@kitware.com wrote:
 On Tue, Jun 09, 2015 at 11:24:03 -0400, David Cole via cmake-developers wrote:
 Is there a single example of a policy wherein the OLD behavior has
 actually been removed?

 Technically, yes. CMP0053 as NEW ignores CMP0010's setting and treats it
 as NEW (because the new parser doesn't implement the OLD behavior at
 all). But CMP0010 is one of those almost assuredly a bug policies and
 really easy to fix (just escape the '$' or add the closing '}').

 --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] C# support?

[David Cole via cmake-developers]

Yes, please do spell it out as CSharp. CS could mean about a billion things...

On Tue, Jun 30, 2015 at 5:19 AM, Stuermer, Michael  SP/HZA-ZSEP
michael.stuer...@schaeffler.com wrote:
 Sounds reasonable,



 my choice was motivated by the file extension of the C# source files (.cs)
 and that it is shorter. But as Fortran seems to use the longer “Fortran”
 description it might be a good idea to switch to “CSharp” as well …



 Michael



 From: Petr Kmoch [mailto:petr.km...@gmail.com]
 Sent: Tuesday, June 30, 2015 10:18 AM
 To: Stuermer, Michael SP/HZA-ZSEP
 Cc: cmake-developers@cmake.org
 Subject: Re: [cmake-developers] C# support?



 On Tue, Jun 30, 2015 at 9:21 AM, Stuermer, Michael SP/HZA-ZSEP
 michael.stuer...@schaeffler.com wrote:

 [...]

 About the language:

 Would it be ok to name the language in CMake CS instead of CSharp? I did
 everything as CS so far...



 If I may provide an outsider's comment on this point, I would suggest
 against this. For me, CS does not intuitively associate with C# - I
 wouldn't know it means C# unless I read it somewhere stated explicitly. C,
 CXX, Fortran are all obvious to me, CS is not.

 Then again, I have never used C#, so it might just be general unfamiliarity
 on my part, in which case feel free to ignore this post.

 Petr




 --

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

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] C# support?

[David Cole via cmake-developers]

The C# compiler, csc.exe, takes all its arguments at once in one call
to build a library or executable. Listing all the sources, and its
references (other libraries it depends on) all at once. You can do it
as command line arguments, or as contents of a response file, or a
combination or arguments plus response file.

Conceptually, it's just like Java.

They do have separate project files for it with VS, though. The
generators will need code to generate *.csproj files, rather than
custom commands in a vcxproj file, to make it seem like it's really
well-integrated with VS. Not sure if *.csproj files have evolved much
over the last few releases of VS -- I'd expect the major challenge
with this to be making sure CMake generates proper *.csproj files for
however many versions of VS it would take to make it acceptable.


D



On Mon, Jun 29, 2015 at 1:05 PM, Brad King brad.k...@kitware.com wrote:
 On 06/26/2015 10:47 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
 Does it have a realistic chance to be accepted for upstream

 Yes, so long as it comes with proper tests and is not too intrusive
 on the overall design/implementation of CMake.

 In order to enable use of C# sources we should get

  enable_language(CSharp)

 to work.  This is likely straightforward with the VS generators.

 One question is how things should be done for the Makefile and
 Ninja generators.  For these we need to construct command line
 invocations of the compiler.  I'm not very familiar with C#.
 Does it need separate compilation with dependencies or should one
 simply invoke the compiler with the entire list of sources in
 a response file or something?

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

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] [CMake] Virtual folders in Visual studio get expanded on reload

[David Cole via cmake-developers]

I think I have seen this behavior in pure (non-CMake-generated) VS
projects... Perhaps it's simply a Visual Studio issue, and has nothing
to do with CMake.

D

On Fri, Jun 12, 2015 at 7:55 AM, Roman Wüger roman.wue...@gmx.at wrote:
 @kgt: Thank you for this great hint. :-)
 I had overlooked this button in Visual Studio

 @mjklaim: I didn't see this behavior in older CMake versions.

 Roman

 -Ursprüngliche Nachricht-
 Von: Thompson, KT [mailto:k...@lanl.gov]
 Gesendet: Dienstag, 02. Juni 2015 15:52
 An: Roman Wüger; CMake MailingList
 Betreff: RE: [cmake-developers] Virtual folders in Visual studio get expanded
 on reload

 Roman,

 I have the same complaint. My project has about 300 targets arranged in two
 dozen folders.  I use the collapse all  button in Visual Studio's Solution
 Explorer window (looks like a stack of 3 squares in VS2013).

 kt

 -Original Message-
 From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
 On Behalf Of Roman Wüger
 Sent: Monday, June 01, 2015 5:00 PM
 To: CMake Developer MailingList; CMake MailingList
 Subject: [cmake-developers] Virtual folders in Visual studio get expanded on
 reload

 Hi,

 I noticed that sometimes when a target is reloaded, that the virtual folders
 and targets for the complete visual studio solution get expanded.
 For a small project this isn't a problem, but in a large project (~ 100 
 targets)
 this is a really big problem to close all targets every time.

 Did anybody noticed this behavior and has a solution for it?

 Thanks

 Best Regards
 Roman
 --

 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

 --

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

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] File Building issue

[David Cole via cmake-developers]

Can you change your CMake minimum required version to 3.3?

On Wed, Jun 10, 2015 at 10:11 AM, Arunava Nag arunavos...@gmail.com wrote:
 Hello,
 Facing an issue while building in cmake 3.3.0. Need some help.

 cmakelist file code extract

 cmake_minimum_required(VERSION 2.8) project(AMFIO) #Flags for compilers if
 (${CMAKE_CXX_COMPILER_ID} STREQUAL Clang)   # using Clang
 (CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wall -Wextra -pedantic -std=c++11)
 elseif (${CMAKE_CXX_COMPILER_ID} STREQUAL GNU)  # using GCC
   SET(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -Wall -Wextra -Werror -Wpedantic
 -std=c++11) endif() #Debug and profiling settings #SET (CMAKE_BUILD_TYPE
 Debug)


 Error received while configuring in cmake:
 Description:
 CMake Warning (dev) at CMakeLists.txt:6 (if):
   Policy CMP0054 is not set: Only interpret if() arguments as variables or
   keywords when unquoted.  Run cmake --help-policy CMP0054 for policy
   details.  Use the cmake_policy command to set the policy and suppress this
   warning.

   Quoted variables like MSVC will no longer be dereferenced when the
 policy
   is set to NEW.  Since the policy is not set the OLD behavior will be used.
 This warning is for project developers.  Use -Wno-dev to suppress it.

 CMake Warning (dev) at CMakeLists.txt:11 (elseif):
   Policy CMP0054 is not set: Only interpret if() arguments as variables or
   keywords when unquoted.  Run cmake --help-policy CMP0054 for policy
   details.  Use the cmake_policy command to set the policy and suppress this
   warning.

   Quoted variables like MSVC will no longer be dereferenced when the
 policy
   is set to NEW.  Since the policy is not set the OLD behavior will be used.
 This warning is for project developers.  Use -Wno-dev to suppress it.

 Thank You

 Regards,
 Arunava Nag

 --

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

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] A policy for Policies

[David Cole via cmake-developers]

So, when you're saying:

...but still supporting the OLD stuff with a warning if no one tried
explicitly to set things to use OLD, they just had a working build
system.

You're effectively saying we will never remove the OLD behavior for
any policies, ever?

If that's the case, then why bother even having policies?





On Wed, Jun 10, 2015 at 5:17 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
 On 6/10/2015 4:57 PM, Alexander Neundorf wrote:

 If the conclusion would be a policy is removed after 5 years, it's
 deadline
 could even be part of the error/warning message right from the point when
 it
 is introduced (you are relying on CMP1234 OLD behaviour. This will be
 removed
 June 2020.).

 Then I could (at work) ignore this maybe until 2017 or 2018, and then it
 would
 slowly rise in my priority, and at some point I would fix it in some spare
 time.

 I guess what we want to do is to come up with a system where the fix is
 not to just add OLD.   We want to be able to build old releases of projects
 and not break them.  However, if we change something that requires changes
 in the CMakeLists.txt we don't want the developers to just set to OLD, we
 want them to fix it.  If someone goes to the trouble of editing the
 CMakeLists.txt, they should just do the fix not set to OLD to shut up the
 warning.

 There is also a whole bunch of users of CMake that have never written a
 single line of CMake code.  They just build software and follow
 instructions.  We want to try real hard to make things work for them and not
 to have a version of CMake nightmare for them.

 So, erroring on OLD earlier might work, but still supporting the OLD stuff
 with a warning if no one tried explicitly to set things to use OLD, they
 just had a working build system.

 -Bill


 --

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

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] A policy for Policies

[David Cole via cmake-developers]

Is there a single example of a policy wherein the OLD behavior has
actually been removed?

Contributing to the problem is this: despite the policy mechanism, OLD
behavior is never actually removed.

Therefore, people know they can just set OLD and move on.

The first policy was introduced in CMake v2.6.0, which is now just
over 7 years old. The first 11 policies were introduced in v2.6.x, all
more than 6 years old now. Would any of them be candidates for
actually removing the OLD behavior now?

It would good for all of us to understand exactly what it looks like
to remove an OLD behavior.

Is there an example series of commits anywhere (even on a side-branch
or in patch-file form) which show removing an OLD behavior and
updating the associated policy code to deal with it?

Good discussion in this thread, by the way. Very informative.


David C.



On Tue, Jun 9, 2015 at 9:42 AM, Brad King brad.k...@kitware.com wrote:
 On 06/08/2015 08:43 PM, Fraser Hutchison wrote:
 As a CMake user, I have a couple of observations here.

 Thanks for coming forward to discuss this!

 users will be more likely to hit the page for the specific policy
 they're interested  in, along with the page for the cmake_policy. None
 of these pages gives even a hint that setting a policy to OLD is
 discouraged.

 Good point.  This should take care of that:

  Help: Document explicitly that policy OLD behavior is deprecated
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=482a3bf3

 From my own perspective, runtime warnings would be the best way to
 encourage me to use a different option other than setting a policy to OLD.

 Yes.

 The intention originally was that the warning about the policy not
 being set would prompt project authors to port to the NEW behavior
 and set the policy.  The only reason for the OLD setting is to
 disable the warning in stable release branches and such.

 I think this discussion has led us to understand that we need a
 second warning about setting the policy to OLD, but not immediately.
 A few releases before policy OLD behavior is to actually be removed
 we could add a runtime warning for code that does not set it to
 NEW implicitly or explicitly.  The only way to turn off this second
 warning (aside from -Wno-dev) would be to set the policy to NEW.
 This would give straggling projects another chance to port.

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

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] NMake Batch-Mode Rules (was: Inquiry on contribution to NMake generator)

[David Cole via cmake-developers]

CMake + Ninja is definitely the best move you can make for giving your
developers the minimum possible build time on Windows.

NMake is basically useless, its underlying code hasn't been updated in
years, and it does absolutely nothing to try to take advantage of
multiple cores.

Fastest Windows build time in recent years has always been ninja
driving the build in my experience. And I've tried the comparisons
several times on projects small and large. It always gives at least
some improvement over other techniques on real world projects.


HTH,
David C.



On Mon, Jun 1, 2015 at 6:55 AM, Florent Castelli
florent.caste...@gmail.com wrote:
 At my company, we didn’t bother trying to use NMake.
 We used the Visual Studio solution generator and the proper compilation
 flags and msbuild flags to build in parallel. This proved to speedup our
 builds quite a lot and was very easy to integrate.
 The other solution you mentioned is “ninja” and sped up our builds even
 more. The msbuild tool is not smart enough and with a number of targets high
 enough and enough files per target, you can just generate n^2 parallel
 compilation processes, which can be counter productive. Though, you can
 manually specify the parallelism factor you want for both msbuild and cl.exe
 and you get decent results.

 Give those a shot, NMake is deprecated in Visual Studio land and has been
 superseded by msbuild.

 And if your devs complain about having to install some tools before
 compiling, just give them a script that downloads and setup CMake and Ninja
 on their system. It’s easy to do and should reduce the number of complaints!

 Regards,
 Florent

 On 01 Jun 2015, at 11:10, Nagy-Egri MĂĄtĂŠ Ferenc via cmake-developers
 cmake-developers@cmake.org wrote:

 Thanks Brad for the detailed description. From what I’ve read about the 3
 level makefile system, it should be pretty straightforward to implement
 batch-mode support.

 Actual compilation takes place only in the last level, and throughout
 generation, this is the point where all the compilation options are present.
 Obtaining a list of files with identical compiler switches might be tricky.
 Depends on how CMake handles this in code internally. I’ll see once I dive
 into code. Deferred generation of the makefile is not nice, but might be the
 only way. Handling the exact location of the object files might be another
 property source files must match.

 As far as I’ve seen NMake is not able to call multiple makefiles in
 parallel, so source-level parallelism might be the most NMake could do, but
 for large projects that could be sufficient.

 Feladó: Brad King
 Elküldve: ‎szerda‎, ‎2015‎. ‎május‎ ‎27‎. ‎20‎:‎13
 Címzett: Nagy-Egri MC!tC) Ferenc
 Másolat: cmake-developers@cmake.org

 On 05/27/2015 01:33 PM, Nagy-Egri MC!tC) Ferenc via cmake-developers wrote:
 like to see the NMake generator finally support multicore builds by
 adding Batch Mode support to the generated makefiles.

 For reference, Batch-Mode Rules are documented here:

  https://msdn.microsoft.com/en-us/library/f2x0zs74.aspx

 They support specifying multiple source files to a single cl invocation,
 as in

  cl -c src1.cpp src2.cpp

 instead of

  cl -c src1.cpp
  cl -c src2.cpp

 Any multi-core utilization occurs inside cl and NMake is not aware of it.

 I have read on the CMake user mailing list, that the problem with
 Batch Mode support, is that it is not trivial to implement.

 It is very hard to implement and may not be possible at all.  See below.

   * What is the design of the NMake generator in CMake?
   * What is the pourpose of having so many makefiles?

 http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F

   * What is the reason why it is not trivial to implement batch mode?

 The main reasons are:

 * CMake generates a separate compilation line for each source in each
   target and the flags may differ across sources and targets.  CMake
   does not use pattern rules for any make backend.

 * CMake needs to control the location of the object files and cl does
   not allow this when more than one source is given.

 Implementing batch mode rules would require teaching the generator to
 somehow recognize when a group of sources are all built with the same
 flags and generate a batch mode rule that matches exactly those sources
 and no others (likely the hardest part).  This grouping would also have
 to account for the names that cl generates for the object files to avoid
 conflicts within a group.  I do not know if generating a proper batch mode
 rule is possible in general.

   * Where should I start browsing the source files?

 One place is Source/cmLocalUnixMakefileGenerator3.cxx but there is no
 specific spot to make a change like this.  It would likely involve
 major refactoring.

 One can achieve multi-core builds without third-party tools by using
 the VS IDE generators.  It is still possible to build from the command
 line with these.

 -Brad

 --

 Powered by 

Re: [cmake-developers] Unittests with reconfiguration

[David Cole via cmake-developers]

This one:
https://github.com/Kitware/CMake/blob/master/Tests/CMakeTestMultipleConfigures/RunCMake.cmake

It doesn't change anything in between CMake configures, but it does 7
altogether, with the expectation that the output will not change
beyond the 1st / 2nd configures.

Sample output here:
https://open.cdash.org/testDetails.php?test=331119724build=3788470

The test doesn't presently fail if there are diffs between configures.
Although one could argue, maybe it should...

You could definitely do something similar for a test that changes a
cache value in between runs.


HTH,
David C.



On Mon, Apr 27, 2015 at 4:13 AM, Raffi Enficiaud
raffi.enfici...@mines-paris.org wrote:
 Hi,

 I would like to know if it is possible to have a unit test with two runs of
 cmake, simulating a user change of the cache in between.

 The workflow would be the following:
 - run cmake with default options, cache entries automatically populated
 - change some cache value
 - run cmake again and check the output and cache output

 I am right now looking at RunCMake but I do not think this scheme is
 suitable for that.

 Would anyone point me to some test already performing that?

 Many thanks,
 Raffi

 --

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

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] Unittests with reconfiguration

[David Cole via cmake-developers]

This chunk in the CMakeLists file is what sets up the arguments for
that test script:
https://github.com/Kitware/CMake/blob/master/Tests/CMakeLists.txt#L1132

D


On Mon, Apr 27, 2015 at 7:16 AM, David Cole dlrd...@aol.com wrote:
 This one:
 https://github.com/Kitware/CMake/blob/master/Tests/CMakeTestMultipleConfigures/RunCMake.cmake

 It doesn't change anything in between CMake configures, but it does 7
 altogether, with the expectation that the output will not change
 beyond the 1st / 2nd configures.

 Sample output here:
 https://open.cdash.org/testDetails.php?test=331119724build=3788470

 The test doesn't presently fail if there are diffs between configures.
 Although one could argue, maybe it should...

 You could definitely do something similar for a test that changes a
 cache value in between runs.


 HTH,
 David C.



 On Mon, Apr 27, 2015 at 4:13 AM, Raffi Enficiaud
 raffi.enfici...@mines-paris.org wrote:
 Hi,

 I would like to know if it is possible to have a unit test with two runs of
 cmake, simulating a user change of the cache in between.

 The workflow would be the following:
 - run cmake with default options, cache entries automatically populated
 - change some cache value
 - run cmake again and check the output and cache output

 I am right now looking at RunCMake but I do not think this scheme is
 suitable for that.

 Would anyone point me to some test already performing that?

 Many thanks,
 Raffi

 --

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

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] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add

[David Cole via cmake-developers]

I realize that sometimes dependencies are necessary.

But.

There's a very strong argument to be made that projects should not
have a lot of external dependencies.

If you really need to tell an ExternalProject build this external
project the same way as the main one, you should probably write code
(perhaps a wrapper of ExternalProject itself) that literally passes
the entire CMakeCache.txt of the main project down to the external
project.

I really don't see how you solve the problem by having a toolchain
file and some arbitrary set of variables to be passed down. Either you
have to put the CMAKE_TOOLCHAIN_ARGS into the toolchain file itself,
or you have to specify the complete set of what defines
CMAKE_TOOLCHAIN_ARGS. If you have a set, how do you add to it? Why not
just have them in the file? If the set changes from project to project
or toolchain to toolchain, then how can you define it so that it's
generally useful?


D




On Sun, Apr 26, 2015 at 8:53 PM, Andrey Pokrovskiy
wonder.m...@gmail.com wrote:
 Because it will be an ad-hoc solution. Also each time I will start
 using a new toolchain file (for another device/platform) I will need
 to modify that wrapper script. And each time I will override some
 toolchain variable I will need to look into that wrapper to verify
 that this variable will be forwarded. Wouldn't it be nice if there was
 a simple way to tell build this external project the same way as a
 main one?

 I'm not saying that the problem is unsolvable. I'm saying that right
 now CMake is not very convenient for projects with a lot of external
 dependencies. And specifying toolchain and it's options is a one
 aspect of it (not the most important, though).


 On Sun, Apr 26, 2015 at 5:36 PM, David Cole dlrd...@aol.com wrote:
 Why wouldn't you just write your own toolchain wrapper file which
 has all the variables you speak of, but also includes the real
 toolchain file, and then use the wrapper as your CMAKE_TOOLCHAIN_FILE
 value ... ?


 D



 On Sun, Apr 26, 2015 at 7:32 PM, Andrey Pokrovskiy
 wonder.m...@gmail.com wrote:
 Hi,

 I'm using cmake and CMAKE_TOOLCHAIN_FILE to build the project and it's
 dependencies. Some toolchain files have additional options (like API
 version, target architecture, linker type, etc.) which you need to
 pass to cmake command with -D in addition to the
 -DCMAKE_TOOLCHAIN_FILE= itself.

 So when you want to build some dependency with ExternalProject_Add()
 it's not enough to pass the same CMAKE_TOOLCHAIN_FILE. You also need
 to explicitly specify all other toolchain variables that you care
 about. That means that each time you start to override another
 toolchain variables or add a new toolchain, you need to carefully add
 proper variable forwardings to each ExternalProject_Add() call. This
 is not convenient and error prone.

 What do you think about formalizing toolchains a bit further? For
 example, it would be nice to have a way to get all variables (with
 their values) that are relevant for the current toolchain. Consider:

 ExternalProject_Add(websockets_ep
 CMAKE_ARGS
 -DCMAKE_TOOLCHAIN_FILE:string=${CMAKE_TOOLCHAIN_FILE}
 -DCMAKE_TOOLCHAIN_ARGS:string=${CMAKE_TOOLCHAIN_ARGS})

 Where ${CMAKE_TOOLCHAIN_ARGS} expands to VAR1=VAL1;VAR2=VAL2; (I
 realize that will not work like that, but conceptually) which defines
 toolchain configuration.

 For example, well behaved toolchain file could be asked to mark each
 configuration variable:

 toolchain_option(ANDROID_NATIVE_API_LEVEL)

 so CMake after processing of a toolchain file can have a list of all
 relevant variables. Or maybe CMake can track all variables touched
 by the toolchain file.

 What do you think about that?
 --

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

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

Re: [cmake-developers] [CMake] cmake 3.1.1 does not generate x64 profile for visual studio

[David Cole via cmake-developers]

We really shouldn't have removed the explicit mention of the  Win64
suffixed generator names in the list of generators in --help ouput...

That was a mistake.

We should put it back.



On Fri, Apr 24, 2015 at 5:29 AM, Xi Shen davidshe...@gmail.com wrote:
 Ah~, so it's a hidden feature? OK, I will give a try.

 Thanks,
 David


 On Fri, 24 Apr 2015 16:38 J Decker d3c...@gmail.com wrote:

 there's a 64 bit generator...
 used to be a separate generator visual studio 12 2013 Win64 but it
 doesn't show in the list of generators now...

 On Thu, Apr 23, 2015 at 11:27 PM, Xi Shen davidshe...@gmail.com wrote:

 Hi,

 I am using cmake 3.1.1 on my Windows 7 64bit system. I have Visual Studio
 2013 installed.

 The project I created with cmake works and can build with msbuild. But it
 only build the x86 version. If I try:

   msbuild /property:Platform=x64 myproj.vcproj

 I got error says that the x64 profile does not exist.

 I have to open the project file and create the x64 profile by myself. Is
 there any way to let cmake generate the x64 profile?


 Thanks,
 David


 --

 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



 --

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

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] [CMake] cmake 3.1.1 does not generate x64 profile for visual studio

[David Cole via cmake-developers]

Excellent. Thanks for the pointer... I had not seen that recent commit.

Seems we had a shared this should be explained better so we don't get
so much email about it brain wave pattern.


Happy Friday,
D


On Fri, Apr 24, 2015 at 9:04 AM, Nils Gladitz nilsglad...@gmail.com wrote:
 On 04/24/2015 02:40 PM, Nils Gladitz wrote:

 Maybe instead of listing all known permutations in --help each generator
 (where the option is supported) could be listed with a well known subset
 of supported target platforms.


 Never mind ... apparently Brad already did that (except with generators
 suffixes rather than -A):

 http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=1e3843373f8e0dfd550809ec034d535d31276b6b

 Nils

-- 

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] ExternalProject can't have interface library as a dependency

[David Cole via cmake-developers]

To avoid this entirely, you can just use add_dependencies (
http://www.cmake.org/cmake/help/v3.2/command/add_dependencies.html )
instead of adding it as a DEPENDS to your ExternalProject_Add call.

The reason ExternalProject_Add queries to see if the other thing is an
ExternalProject or not is to set up file level dependencies between a
step of that project and the configure step of this project. If it is,
it sets it up... if not, it has the same effect as a direct
add_dependencies call.

(But I have no idea why there are even whitelisted properties to tell
you the truth. I've been reading along here waiting for somebody
to explain that one. ;-)


HTH,
David



On Tue, Apr 21, 2015 at 3:34 AM, Andrey Pokrovskiy
wonder.m...@gmail.com wrote:
 [Moved from cmake users mailing list]

 I have the following construction:

 ExternalProject_Add(
 websockets_ep
 DEPENDS ev openssl
 ...)

 But it so happened, that openssl is an INTERFACE library. It is an
 INTERFACE library, because I created it with add_library(openssl
 INTEFACE) and then populated corresponding INCLUDE and LINK
 properties. And I get an obscure error:

 CMake Error at 
 /usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2031
 (get_property):
   INTERFACE_LIBRARY targets may only have whitelisted properties.  The
   property _EP_IS_EXTERNAL_PROJECT is not allowed.
 Call Stack (most recent call first):
   /usr/share/cmake/share/cmake-3.2/Modules/ExternalProject.cmake:2328
 (_ep_add_configure_command)
   src/libwebsockets/CMakeLists.txt:21 (ExternalProject_Add)

 Apparently because there is a check inside get_property() that
 whitelists what properties could be queried.

 My first idea was that having a whitelist for get_property() is
 probably not that good idea.
 But then I realized that I don't understand why ExternalProject cares
 about whether dependency is also an external project. What the
 difference it makes? Does that means that it's not safe to use
 external project target with add_dependencies()?

 ExternalProject_Add() already have code that should cover all cases:

   # Depend on other external projects (target-level).
   get_property(deps TARGET ${name} PROPERTY _EP_DEPENDS)
   foreach(arg IN LISTS deps)
 add_dependencies(${name} ${arg})
   endforeach()

 Why there is a special case when dependency is also an external project?
 --

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

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] [PATCH] ExternalProject_Add: Allow generator expressions in CMAKE_CACHE_ARGS

[David Cole via cmake-developers]

With this change, does the external project's configure step re-run
when you edit only the CMAKE_CACHE_ARGS for it?

(It did with the *.in / configure_file approach...)


On Fri, Apr 17, 2015 at 12:55 AM, Andrey Pokrovskiy
wonder.m...@gmail.com wrote:
 In current implementation of ExternalProject_Add generator expressions
 are supported in CMAKE_ARGS (probably by coincidence), but not in
 CMAKE_CACHE_ARGS. This patch will enable generators expressions in
 CMAKE_CACHE_ARGS.

 Use case:
 set(LIBEV_LIBRARIES $TARGET_FILE:ev)
 ExternalProject_Add(
 ...
 CMAKE_CACHE_ARGS
  -DLIBEV_LIBRARIES=${LIBEV_LIBRARIES}
 ...)

 ---
  Modules/ExternalProject.cmake | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

 diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
 index 0c73d41..1c7cf51 100644
 --- a/Modules/ExternalProject.cmake
 +++ b/Modules/ExternalProject.cmake
 @@ -1126,10 +1126,7 @@ function(_ep_write_initial_cache target_name
 script_filename script_initial_cach
# Replace location tags.
_ep_replace_location_tags(${target_name} script_initial_cache)
# Write out the initial cache file to the location specified.
 -  if(NOT EXISTS ${script_filename}.in)
 -file(WRITE ${script_filename}.in \@script_initial_cache\@\n)
 -  endif()
 -  configure_file(${script_filename}.in ${script_filename})
 +  file(GENERATE OUTPUT ${script_filename} CONTENT 
 ${script_initial_cache})
  endfunction()


 --
 2.3.2 (Apple Git-55)

 --

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

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] [PATCH 0/9] Xcode: Generate stable project files

[David Cole via cmake-developers]

Nice!!

I agree with Eike: perhaps you could start the patch series by putting the
verbose explanation in the text of the first commit, and explain the
following 8... commits all help to minimize the diffs between CMake
generated project files and Xcode native project files.

I love it when people get into cleaning stuff up - little things like this
make all the difference when you're trying to analyze how something's put
together.

Thanks for the effort


On Monday, April 13, 2015, Rolf Eike Beer e...@sf-mail.de wrote:

 Am Montag, 13. April 2015, 21:37:57 schrieb Gregor Jasny:
  Hello,
 
  this patch series aims to minimize deltas between the CMake Xcode
  generator and Xcode itself. It was started by the observation that
  if one makes any change to the project within Xcode (e.g. to see
  how a variable is called internally) the user cannot diff the CMake
  project and the one stored by Xcode afterwards.
 
  The major difference now is that Xcode objects are sorted before
  project generation so that they appear sorted within the individual
  sections.
 
  Indention is done by using tabs instead of seven spaces.
 
  I tested this series with Xcode 6.3 and Xcode 3.2. Both show a
  reduced diff after this series was applied.

 This explanation will be lost when the patches are applied, therefore I
 would
 like to see parts of these text in the individual commit messages, e.g.
 just
 add a as Xcode itself does to the change from spaces to tabs.

 Greetings,

 Eike
-- 

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] Generating buildsystem metadata from CMake

[David Cole via cmake-developers]

I favor documenting the existing format, too.

Note added to issue with my vote.


D


On Wed, Apr 1, 2015 at 4:26 PM, Stephen Kelly steve...@gmail.com wrote:
 Anton Makeev wrote:

 Not only do we reed it, we also have the UI that allows user to interact
 and  the cached values. That means we’ll have CMakeCache parser anyways
 and do not need these values in metadata.json file, as it was mentioned in
 parallel discussion.

 Yes, that's what I thought. I favor documenting the existing format instead
 of adding a new json format for it. I filed

  http://public.kitware.com/Bug/view.php?id=15490

 to track the idea.

 Thanks,

 Steve.


 --

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

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] A CMAKE_EMULATOR variable

[David Cole via cmake-developers]

What does CMAKE_EMULATOR emulate?

From its name, it sounds like it emulates CMake. But from your description,
I'm thinking that doesn't make sense... Because you actually run CMake and
pass it CMAKE_EMULATOR. So it must be emulating something else while
running CMake?

I'm guessing it emulates the target system when cross-compiling, and
executables built for the target system can be run when passed to the
emulator? Is that right?


D



On Wednesday, March 4, 2015, Matt McCormick matt.mccorm...@kitware.com
wrote:

 Hi,

 I have pushed to stage [1] support for a CMAKE_EMULATOR variable to
 help when cross-compiling.  The goal is to improve cross compiling
 with CMake by making it easier to build and run tests.  In principle,
 the commands

   cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake
 -DCMAKE_EMULATOR=/path/to/emulator ~/src/project
   cmake -D Experimental

 are all that is needed generate a dashboard report, complete with test
 results.  This should inch C/C++ closer to being the write once, run
 anywhere languages :-).

 The emulator is used to run try_run results, which avoids manual
 population of TryRunResults.cmake.  This can be a painful,
 time-consuming process otherwise.

 It is also used to run tests on executables that are built for the
 target system.  Without this approach, it is difficult to know which
 tests should be executed on the target system.  Tests are often passed
 absolute paths to input on the host system.  The use of an emulator is
 a way to avoid complexities and transfer overhead related to
 reproducing the host filesystem on the target filesystem to run the
 tests.


 With some fixes to ITK [2], this was used to build and test for four
 cases of interest.

 The emulator approach works best with MinGW and WINE to build and test
 on Linux for Windows [3].

 The qemu-arm emulator provided by QEMU User Mode can be used with the
 Android NDK toolchain [4]. A gotcha is that Android tries to be fancy
 and uses its own dynamic loader.  To get around this, I tested with
 completely static executables.  Also, QEMU User Mode does not
 currently support multi-threading well, so tests were run
 single-threaded. An alternative approach may be to use an emulator
 script that is a wrapper around adb.

 The qemu-arm emulator was used again with the Raspberry Pi toolchain
 [5].  A symbolic link was created in the expected location for
 ld-linux-armhf.so.3, and dynamic loading works.  To run the tests,
 LD_LIBRARY_PATH was populated with the path to libc and libstdcxx.

 One of the most interesting combinations is the Emscripten toolchain
 with NodeJS as the emulator [6]. There are some WIP workarounds to get
 Emscripten to configure cleanly for scientific libraries [7], and code
 had to be injected into the test driver to mount local filesystems for
 node, but this works surprisingly well.


 Testing and feedback are appreciated.

 Thanks,
 Matt


 [1]
 http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/emulator

 [2] https://github.com/thewtex/ITK/tree/cmake-emulator

 [3] https://open.cdash.org/buildSummary.php?buildid=3694578

 [4] https://open.cdash.org/buildSummary.php?buildid=3694810

 [5] https://open.cdash.org/buildSummary.php?buildid=3694810

 [6] https://open.cdash.org/buildSummary.php?buildid=3705525

 [7] https://github.com/thewtex/emscripten/tree/test-big-endian
 --

 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

-- 

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] Feature request in CMake-gui: Open project file button

[David Cole via cmake-developers]

There is a similar (old) feature request in the bug tracker for a
build button:

http://public.kitware.com/Bug/view.php?id=8260

See the commentary there when considering adding a button to cmake-gui...


D



On Thu, Feb 5, 2015 at 4:54 AM, Paul Anton Letnes p...@letnes.com wrote:
 Hi!

 I sometimes dream of a tiny, but time-saving feature: Next to configure
 and generate, I'd want an open project button (for VS/Eclipse/XCode or
 other IDE projects).

 Cheers
 ---
 Paul Anton

 --

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

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] Cmake 2.8.8 -- can't find curses.h

[David Cole via cmake-developers]

This is a pre-built Linux binary that should work on that system, and
should include ccmake:

http://www.cmake.org/files/v2.8/cmake-2.8.8-Linux-i386.tar.gz

If you can't run it, it's probably because you're on an x64 box, and
you need the run the 32-bit exes and libs library -- hopefully
somebody else can chime in with the package to install, because I can
never remember the name of it.


HTH,
David C.



On Wed, Jan 21, 2015 at 10:57 AM, Sharath Prasad
prasad.shar...@gmail.com wrote:
 Hello.

 I am trying to use a specific version of cmake (v2.8.8). I also need ccmake
 (v2.8.8). I located the folders uploaded for this release. I plan to use it
 on ubuntu. I downloaded cmake folders and extracted all the folders related
 to Linux. However, only one folder has options to build from scratch. Other
 folders have binaries that do not run on my machine.

 The folder that compiles from scratch cannot locate CURSES or NCURSES and
 has trouble locating curses.h

 So ccmake does not work. If I install ccmake, it updates to the latest
 version 2.8.12 or so.

 I need v2.8.8 specifically, Can you help?


 Thanks,
 Sharath

 --

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

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] DragNDrop: Easier custom dmg layouts

[David Cole via cmake-developers]

This looks pretty reasonable to me. From Rob's initial email, I
thought it sounded like there was some sort of backward compatibility
problem, but looking through the code, it seems like everything should
all work the same for projects that aren't changing. Was I
misunderstanding about backwards compatibility, or am I missing
something?

And although I haven't built it or run it myself yet, I trust that if
the DMG produced for CMake looks good, that people can model their own
code after CMake's own code to achieve better looking DMG installers.

Personally, I am stuck on what I consider to be a very old Mac right
now. It's a mini from ~2007-2008, and it's stuck running 10.6. I use
it only when I absolutely have to (i.e. for virtually nothing) because
it's so much slower than other machines I use. My point with
mentioning this at all is to encourage you to drop support entirely
for 10.6 at this point. (i.e. -- put this topic back in 'next' and
retire those old Macs... they're tired... :-)

Nice work, Rob.

Thanks,
David C.



On Tue, Dec 23, 2014 at 9:01 AM, Brad King brad.k...@kitware.com wrote:
 On 12/22/2014 02:15 PM, Robert Maynard wrote:
 If anyone has any questions or issues with this branch please tell me.

 I'd appreciate feedback on this from others with experience in
 OS X packaging.  For reference, the commit drafts are:

  DragNDropGenerator background image now uses source file extension.
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c8b9f50

  DragNDropGenerator now places the background image file in a hidden folder.
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7f55ac9

  DragNDropGenerator now can run an apple script when making a package.
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=309ffd8e

  DragNDropGenerator copies the background image after the dmg is created.
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2dc198b2

  DragNDropGenerator now manually computes the size of the temp dmg image.
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dfb74f52

  DragNDropGenerator Updated Documentation to include new variables.
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=76a39f7a

  CMake DragNDrop release now uses a custom background and script
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4549f8ef

 However, for now I had to revert it from 'next' because it does
 not work on OS X = 10.5.

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

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] OpenBSD and srand()/rand() changes

[David Cole via cmake-developers]

Looking at our own internal test suite usage of RANDOM_SEED leads to
the conclusion that we do not verify the sequences produced when
actually using RANDOM_SEED..

So, from our point of view, we don't really care about what effect
RANDOM_SEED has for our test suite. But I think we do still care that
it maintains its existing behavior for folks who are using it: some
clients may depend on it producing a deterministic sequence.

If you don't use RANDOM_SEED, you should get as random a sequence as
possible when using RANDOM. If you do use RANDOM_SEED, you should see
a deterministic sequence for subsequent uses of RANDOM in the same run
of cmake.


Just my opinion,
David C.


On Mon, Dec 15, 2014 at 11:48 AM, Rolf Eike Beer e...@sf-mail.de wrote:
 Brad King wrote:
 On 12/14/2014 08:36 AM, Rolf Eike Beer wrote:
  The idea behind this API in OpenBSD is: if you are looking for the pseudo
  numbers you need to call srand_deterministic(), i.e. you must explicitely
  state that you want the not really random random numbers. Everyone else
  will get real random.

 CMake uses /dev/urandom on POSIX and wincrypt APIs on Windows to choose
 the seed specifically to get really random behavior.  The *only* reason
 we continue to use s/rand() at all is to support the RANDOM_SEED API in
 string(RANDOM), AFAIK.

 One approach to dealing with this is to refactor the implementation of
 string(RANDOM) to use non-deterministic APIs until RANDOM_SEED is used
 and then use deterministic APIs after that.  That will get better random
 values by default but still honor the existing API when it is used.

 Which is what we would get if we do not call srand_deterministic() on OpenBSD
 afaict. We would get weaker random numbers on other platforms, but I doubt
 this matters at all.

 Eike
 --
 --

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

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] OpenBSD and srand()/rand() changes

[David Cole via cmake-developers]

Sounds to me like the perfect thing to just ignore till the dust settles.
And then, after that, if there's no srand/rand on OpenBSD... Well...
There will be, won't there?


On Sunday, December 14, 2014, Rolf Eike Beer e...@sf-mail.de wrote:

 Am Samstag, 13. Dezember 2014, 13:05:00 schrieben Sie:
  On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-developers
 wrote:
   Yes, setting an explicit seed should make subsequent calls to random
   be deterministic...
 
  Well, *we* want that, but I don't think that OpenBSD is making an
  *awful* decision here.
 
  Even if you want deterministic, you're only deterministic on a single
  platform, so if you want to get a deterministicly random (such an odd
  phrase…) sequence, the best thing to do is to code up an Mersenne
  Twister or something and ignore the rand/srand functions.

 Well, srand() and random() have ever been deterministic, and AFAIK using
 the
 same algorhtim and thus the same results on all supporting platforms, so
 it is
 the perfect choice for us. What is happening is that OpenBSD is fighting
 people
 that don't get that this is deterministic.

 Eike
-- 

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] OpenBSD and srand()/rand() changes

[David Cole via cmake-developers]

The utility of the determinism is all about enabling test suites to
pass even if they use random behavior. How the determinism is
achieved, I don't really care.

As long as tests that use random behavior have predictable results.

It doesn't matter to me if they have platform differences. As long as
the expected test results account for any differences that do exist,
the goal can still be satisfied: predictable results.

thx,
D


On Sat, Dec 13, 2014 at 1:05 PM, Ben Boeckel ben.boec...@kitware.com wrote:
 On Thu, Dec 11, 2014 at 14:41:36 -0500, David Cole via cmake-developers wrote:
 Yes, setting an explicit seed should make subsequent calls to random
 be deterministic...

 Well, *we* want that, but I don't think that OpenBSD is making an
 *awful* decision here.

 Even if you want deterministic, you're only deterministic on a single
 platform, so if you want to get a deterministicly random (such an odd
 phrase…) sequence, the best thing to do is to code up an Mersenne
 Twister or something and ignore the rand/srand functions.

 --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] OpenBSD and srand()/rand() changes

[David Cole via cmake-developers]

Yes, setting an explicit seed should make subsequent calls to random
be deterministic...


On Wed, Dec 10, 2014 at 9:50 AM, Rolf Eike Beer e...@sf-mail.de wrote:
 Am 10.12.2014 15:38, schrieb Ben Boeckel:

 Hi,

 It appears[1] as though OpenBSD has changed srand and rand which we use
 in CMake for string(RANDOM) and with the change, RANDOM_SEED will be a
 no-op there.

 Do we want to use rand_deterministic and srand_determinitic or does it
 not matter?


 From what I see there we want to use the deterministic variants. May also
 get us rid of some warnings on OpenBSD.

 Eike

 --

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

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] Failing CMake WinStorePhone tests

[David Cole via cmake-developers]

Well, after installing the Update 4 to VS 2013 yesterday, and letting
the dashboards run their usual course overnight ... the WinStorePhone
tests seem to work just fine now.

So: must be some difference in VS 2013 out of the box and Update 4
that was to blame. I'm perfectly ok with saying you gotta have the
latest update of VS for the WinStorePhone tests to work.

Does that match your expectations?

Thanks, and sorry for the temporary noise


David C.


On Tue, Nov 18, 2014 at 4:20 PM, David Cole dlrd...@aol.com wrote:
 I just put VS 2013 Professional on it within the last two weeks. It
 might be the original release of VS 2013... I have to install Update 4
 for it, but won't be able to get to that until tomorrow.

 So: original VS 2013 Pro, all optional components installed.

 Will this magically go away if I apply the Update 4 tomorrow?

 Let me know if you need more specific information, or if you'd like me
 to try something before you push a commit with a fix.

 Thanks,
 David


 On Mon, Nov 17, 2014 at 8:08 PM, Gilles Khouzam
 gilles.khou...@microsoft.com wrote:
 Hi David,

 Can you give me some information on your current setup? What build of VS do 
 you have installed, which options? I think that the detection logic for the 
 tests is missing some cases. I'm guessing that this is similar to what I 
 recently fixed in CMake for the express editions, the same detection logic 
 might need to be moved over to the test script.

 -Original Message-
 From: David Cole [mailto:dlrd...@aol.com]
 Sent: Friday, November 14, 2014 10:42
 To: Gilles Khouzam
 Cc: Brad King; cmake-developers@cmake.org
 Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests

 I was hoping you'd say that! :-)

 On Fri, Nov 14, 2014 at 12:23 PM, Gilles Khouzam 
 gilles.khou...@microsoft.com wrote:
 Hi David,

 Let me take a look at what's going on.

 -Original Message-
 From: Brad King [mailto:brad.k...@kitware.com]
 Sent: Friday, November 14, 2014 08:38
 To: David Cole
 Cc: cmake-developers@cmake.org; Gilles Khouzam
 Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests

 On 11/14/2014 11:27 AM, David Cole via cmake-developers wrote:
 Should I expect these tests to pass using Ninja, or is that beyond
 the scope of the WinStorePhone support...?

 The VS generator is needed for the feature, but the tests that are failing 
 hard-code use of specific Visual Studio generators regardless of the main 
 generator being tested.

 I'll defer to Gilles as for what the problem might be.

 -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] [PATCH v5 0/4] Add continue keyword

[David Cole via cmake-developers]

Putting continue, break or return inside of a macro definition is a
practice that should itself be discouraged...

(I know, people will probably still have cases of it, but it doesn't
seem like that's what any sane person would label a good practice, let
alone a best practice...)


On Tue, Nov 18, 2014 at 12:31 PM, Ben Boeckel ben.boec...@kitware.com wrote:
 On Tue, Nov 18, 2014 at 18:06:30 +0100, Gregor Jasny wrote:
 On 18/11/14 17:19, Ben Boeckel wrote:
  I wonder if we should
  fix anything about it and if so, make continue behave in an analogous
  way

 You want to make continue() bug compatible to break()?

 There are two parts here:

   1) is there something wrong with the break() example (looking closer
  at CMP0055 shows that, yes, there is)?
   2) if so, do we make continue() act like it before or while fixing
  break()?

 My concern is that with CMP0055 as-is, there is a case where continue()
 works as break() *should* but break() is set to an OLD policy and now
 they can have completely different semantics. If we decide that the
 example *does* show a problem, I'd like *one* policy for continue() and
 break() at the same time. Maybe it's not an issue because continue() is
 a completely new command and already basically moves you up to requiring
 3.2 anyways in which case the mix-and-match behavior is only a problem
 with an explicit-OLD policy setting.

 So the break in the macro worked, the break in the function got ignored.
 This is expected behavior. The macro currently does not form an own
 scope. Also variables set inside escape into the calling scope.

 The function forms an own scope (due to the Push/PopScope call).

 I think it is sane behavior that a macro does not form a scope / loop
 context behavior. Or do you read macro like macro function?

 I guess I should have been more clear: the behavior exhibited is what I
 expected given my experience with macros and functions. It's more of a
 do we fix it?.

  without any error messages (e.g., about using break() outside a

 This is because CMP0055 defaults to OLD here. If you add
 cmake_policy(SET CMP0055 NEW) here you'll get a nice error.

 I think that this and the argument rule should be separate policies
 (removing arguments is easy; refactoring out a now-unallowed behavior
 might be harder depending on how deep down a macro calls break()).

  loop…which doesn't seem to happen anyways, so maybe this is moot). I
  don't see any existing tests about break inside of a function or macro
  having an effect on the caller's logic.

 What do you mean with 'effect' here?

 Calling a macro mutates your control flow (e.g., calling return()) in
 ways functions can't (and there's no distinction between macros and
 functions at the callsite).

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

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] Failing CMake WinStorePhone tests

[David Cole via cmake-developers]

I just put VS 2013 Professional on it within the last two weeks. It
might be the original release of VS 2013... I have to install Update 4
for it, but won't be able to get to that until tomorrow.

So: original VS 2013 Pro, all optional components installed.

Will this magically go away if I apply the Update 4 tomorrow?

Let me know if you need more specific information, or if you'd like me
to try something before you push a commit with a fix.

Thanks,
David


On Mon, Nov 17, 2014 at 8:08 PM, Gilles Khouzam
gilles.khou...@microsoft.com wrote:
 Hi David,

 Can you give me some information on your current setup? What build of VS do 
 you have installed, which options? I think that the detection logic for the 
 tests is missing some cases. I'm guessing that this is similar to what I 
 recently fixed in CMake for the express editions, the same detection logic 
 might need to be moved over to the test script.

 -Original Message-
 From: David Cole [mailto:dlrd...@aol.com]
 Sent: Friday, November 14, 2014 10:42
 To: Gilles Khouzam
 Cc: Brad King; cmake-developers@cmake.org
 Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests

 I was hoping you'd say that! :-)

 On Fri, Nov 14, 2014 at 12:23 PM, Gilles Khouzam 
 gilles.khou...@microsoft.com wrote:
 Hi David,

 Let me take a look at what's going on.

 -Original Message-
 From: Brad King [mailto:brad.k...@kitware.com]
 Sent: Friday, November 14, 2014 08:38
 To: David Cole
 Cc: cmake-developers@cmake.org; Gilles Khouzam
 Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests

 On 11/14/2014 11:27 AM, David Cole via cmake-developers wrote:
 Should I expect these tests to pass using Ninja, or is that beyond
 the scope of the WinStorePhone support...?

 The VS generator is needed for the feature, but the tests that are failing 
 hard-code use of specific Visual Studio generators regardless of the main 
 generator being tested.

 I'll defer to Gilles as for what the problem might be.

 -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] Failing CMake WinStorePhone tests

[David Cole via cmake-developers]

Hi,

The VSWinStorePhone tests are failing on my dashboard submissions:

http://open.cdash.org/viewTest.php?onlyfailedbuildid=3570369
http://open.cdash.org/viewTest.php?onlyfailedbuildid=3570163

I just upgraded that machine to Windows 8.1 and Visual Studio 2013,
and these dashboards run in a VS environment, but with the Ninja
generator.

Should I expect these tests to pass using Ninja, or is that beyond the
scope of the WinStorePhone support...? (i.e. -- do you have to use a
Visual Studio generator for this feature, or should also work with
Ninja, jom or NMake Makefiles?)

Thanks,
David C.
-- 

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] Failing CMake WinStorePhone tests

[David Cole via cmake-developers]

I was hoping you'd say that! :-)

On Fri, Nov 14, 2014 at 12:23 PM, Gilles Khouzam
gilles.khou...@microsoft.com wrote:
 Hi David,

 Let me take a look at what's going on.

 -Original Message-
 From: Brad King [mailto:brad.k...@kitware.com]
 Sent: Friday, November 14, 2014 08:38
 To: David Cole
 Cc: cmake-developers@cmake.org; Gilles Khouzam
 Subject: Re: [cmake-developers] Failing CMake WinStorePhone tests

 On 11/14/2014 11:27 AM, David Cole via cmake-developers wrote:
 Should I expect these tests to pass using Ninja, or is that beyond the
 scope of the WinStorePhone support...?

 The VS generator is needed for the feature, but the tests that are failing 
 hard-code use of specific Visual Studio generators regardless of the main 
 generator being tested.

 I'll defer to Gilles as for what the problem might be.

 -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] CMake 3.1 regression with incremental builds ?

[David Cole via cmake-developers]

I just looked at the diff, not the surrounding code, so forgive the
question if it's obvious when inspecting the code.. but here's a
question about your change before we push it into RC 2:

Is objectSources guaranteed to contain the same set of objects as mapping?

If so, I wonder why the code calls:
cmSourceFile* sf = context-Makefile-GetOrCreateSource(objFile, true);

instead of simply using map_it-first?

i.e. -- isn't the GetOrCreateSourceFile call superfluous if you have a
pointer to the source file object in the iterator...? Or is it a
const thing?


Curious,
David C.


On Thu, Nov 6, 2014 at 11:09 PM, clin...@elemtech.com wrote:

 I've put in a fix for this.
 580b668d genex: Preserve order while evaluating TARGET_OBJECTS

 Can we put this in RC 2?

 Clint

 - Original Message -
 
  Using the netcdf project
  ftp://ftp.unidata.ucar.edu/pub/netcdf/netcdf-4.3.2.tar.gz
 
  I see a problem with incremental builds doing a relink of libraries.  Within
  my project, this leads to unnecessarily relinking of many executables every
  time I run cmake.
 
  For example:
 
  tar zxf netcdf-4.3.2.tar.gz
  cd netcdf-4.3.2
  mkdir build
  cd build
  cmake ../
  git init .
  git add .
  git commit -minit
  cmake ../
  git diff
 
 
  These files have modifications in them which will lead to relinking.
  liblib/CMakeFiles/netcdf.dir/build.make
  liblib/CMakeFiles/netcdf.dir/link.txt
 
  I see object files listed in a random order.  Perhaps there is a std::set
  used
  somewhere in CMake or something.
 
  I do not see this behavior with CMake 3.0.2.
 
  Clint
  --
 
  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
 
 --

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

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] GCC HPPA linker errors

[David Cole via cmake-developers]

These are the earliest CDash results available for CMake:
http://open.cdash.org/index.php?project=CMakedate=2014-07-09

(they're discarded after 120 days...)

On Thu, Nov 6, 2014 at 5:27 PM, Rolf Eike Beer e...@sf-mail.de wrote:

 Am Donnerstag, 6. November 2014, 12:44:12 schrieb Brad King:
  On 11/06/2014 12:00 PM, Chuck Atkins wrote:
   I added an HP-UX block and adjusted the logic to be a bit more
   consistent with the other determine system blocks
 
  Looks good to me, assuming the test for parisc on hpux is correct.

 Chuck, you could try looking back into June/July to see what the HP-UX
 machine
 reported (hpux11.detec). On the other hand the check now only matches
 machines
 that are not Itanium, which is in theory 2 architectures, but I don't think
 that anyone can get CMake to work on an HP-UX m68k machine ;)
 --

 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

-- 

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] cmake-gui icons

[David Cole via cmake-developers]

I would say yes, too.

On Tue, Oct 28, 2014 at 3:27 AM, Daniel Pfeifer dan...@pfeifer-mail.de
wrote:

 2014-10-27 21:33 GMT+01:00 Ben Boeckel ben.boec...@kitware.com:

 On Mon, Oct 27, 2014 at 11:59:09 -0600, Orion Poplawski wrote:
  Trying to bring a bit more attention to this:
 
  Fedora is pushing to have higher resolution icons for the applications.
 There
  already is CMakeSetup128.png, but these would need to get installed
 into the
  proper /usr/share/icons/ hierarchy and named appropriately for the
 correct
  size to be automatically found and used. It would be good to have
 cmake-gui be
  conformant to the current desktop standards.
 
  Related -
 
  http://www.cmake.org/Bug/view.php?id=13504
  http://www.cmake.org/Bug/view.php?id=14315
 
  Also might want to consider shipping AppData information.
 
  http://people.freedesktop.org/~hughsient/appdata/

 I think there's a bug about this too (or at least for appdata). My
 question is: does it really make sense to have appdata for CMake's GUI?
 It isn't an end user application and I feel that developers know
 about CMake's Qt UI (or at least wouldn't look for it in the application
 tool thing).

 (I'm not against AppData overall; just wondering whether it makes sense
 for development tools such as cmake-gui.)

 Others' thoughts?


 I wouds say: Yes, it makes sense.

 There is AppData for Anjuta, Eclipse, KDevelop, QtCreator and the like.
 Those too are tools for developers rather than end users. cmake-gui would
 perfectly fit into that crowd.

 -- Daniel

 --

 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

-- 

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] New command 'file(LOCK_DIRECTORY ...)'

[David Cole via cmake-developers]

What is the main use case for locking files and directories from the
CMake language?

I feel slightly uncomfortable, without being able to put my finger on
exactly why, with the prospect of adding this to CMake...

Behavior when there's a lock that still exists (by bug/mistake) after
CMake is done running is going to be strange and possibly
hard-to-diagnose / hard-to-understand.

Let's make sure the use case is quite strong before we accept the
possibility of stale locks in CMake.


Thanks,
David C.



On Fri, Oct 10, 2014 at 7:45 AM, Ruslan Baratov via cmake-developers
cmake-developers@cmake.org wrote:
 On 08-Oct-14 16:45, Brad King wrote:

 On 10/08/2014 07:52 AM, Ruslan Baratov wrote:

 Okay :) I just not sure that I understand to pass to some other
 process goal correctly.

 That was just an example of why one might want to drop management
 of the lock by CMake without actually unlocking it.  Perhaps the
 code is starting a daemon and passes off responsibility for the
 unlock side to the daemon process.

 Okay, got it.


 * we just need to `unlock` file so the other instance will use it:
 file(UNLOCK_FILE /path/to/shared/file)
 # now anybody can do the lock

 Yes.  We also need the locking API to return information about
 whether we really acquired the lock.

 So it can be TRY_LOCK and LOCK. But does the TRY_LOCK really needed? With
 LOCK we can try to lock and spin until acquire, but what to do with
 TRY_LOCK? Just give up?


 * we need other process to inherit the lock (what for?), i.e. move
 ownership (?):
 file(LOCK_FILE /path/to/shared/file)
 execute_process(${CMAKE_COMMAND} --take-ownership /path/to/shared/file
 ...)
 # unlocked by execute_process

 I think all we need there is a way to ask CMake to take over
 responsibility for a lock that it did not originally create.
 It can also be in the file() command.

 Thanks,
 -Brad

 Okay, so here is the commands inspired by C++:

   file(TRY_LOCK /path/to/file result) # try to lock and return TRUE on
 success (needed?)
   file(LOCK ...) # lock until unlock (unlock by further code (what if
 exit/crashed?) or by deamon)
   file(LOCK_GUARD ...) # lock for scope of current function or until exit
   file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD

 Locking directory is equivalent to locking file `cmake.lock` in directory
 /path/to/shared/directory/:

   file(DIRECTORY_TRY_LOCK ...)
   file(DIRECTORY_LOCK /path/to/shared/directory/) # == file(LOCK
 /path/to/shared/directory/cmake.lock)
   file(DIRECTORY_LOCK_GUARD ...)
   file(DIRECTORY_UNLOCK ...)

 If any of this commands failed (e.g. have no permissions) - exit with
 unsuccessful code (i.e. FATAL_ERROR) ?

 * http://en.cppreference.com/w/cpp/thread/try_lock
 * http://en.cppreference.com/w/cpp/thread/lock
 * http://en.cppreference.com/w/cpp/thread/lock_guard
 * http://en.cppreference.com/w/cpp/thread/mutex/unlock

 --

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

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] Any ideas for accessing the Dart source code?

[David Cole via cmake-developers]

Consider using CDash instead. It was Dart's drop-in replacement...
and is actively maintained today.

www.cdash.org


On Tue, Oct 7, 2014 at 6:46 PM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote:
 I thought it would be interesting to install my own local dart server
 to learn how to use CTest as a dart client.  However, the dart server
 software development effort seems to have a largely broken web
 presence.  For example, http://www.cmake.org/dart/HTML/Install.shtml
 points to a Dart.pdf documentation file that is a broken link.  The
 Dart Wiki at http://na-mic.org/Wiki/index.php/Dart2Summary which is
 recommended by the above cmake.org site is still up and running, but
 it also refers to that same broken link for Dart.pdf. From the Wiki
 the latest Dart release seems to be 1.0.9 (from 7 (!) years ago).  I
 discovered that release does include the Dart.pdf file which is good,
 but only includes jar files and not source code which is bad.  For
 example, I am concerned those 7-year old *.class files in the jar
 files might not run properly with modern java.

 Therefore, I would like to build those jar files from source.  According
 to the above wiki you can get access to the source code using

 svn co http://svn.na-mic.org/svn/Dart/trunk

 but that command immediately returns
 svn: OPTIONS of 'http://svn.na-mic.org/svn/Dart/trunk': 200 OK

 In contrast, Dart.pdf states that source code is available using

 svn checkout http://svn.na-mic.org:8000/svn/Dart

 However, that command times out with cannot connect to server.

 Does anyone here know how to access the Dart source or is that gone
 forever?

 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); the Time
 Ephemerides project (timeephem.sf.net); PLplot scientific plotting
 software package (plplot.sf.net); 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

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

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] Improving the version selection behavior of EXACT

[David Cole via cmake-developers]

How about IN_RANGE and/or IN_SET options?

Where IN_RANGE takes two version numbers (low and high) and does the
equivalent of:

if ( (NOT ver VERSION_LESS low) AND (ver VERSION_LESS high) )

Or possibly even IN_RANGES with multiple ranges...

And IN_SET takes a list of explicit version numbers and looks for
exact matches among multiple choices...?


It's all pie in the sky until you reach up and pull one down. ;-)

D



On Fri, Oct 3, 2014 at 3:35 AM, Rolf Eike Beer e...@sf-mail.de wrote:
 find_package(foo 2.0 EXACT) means EXACT, i.e. only 2.0 is allowed. In most
 cases this behavior is not the one that one would expect or need. Most people
 would instead allow any 2.0.x version to match. This sort of selection is
 currently impossible without additional effort in every Find*.cmake that is
 used.

 I came over this when I tried converting FindLua5[01].cmake to use
 FindLua.cmake, but I can't do find_package(Lua 5.0 EXACT) in there because
 e.g. 5.0.1 would not be accepted then, and I neither can do find_package(Lua
 5.0) because that may return e.g. 5.2 instead.

 Since we can't change this because of the usual backward compatibility
 concerns I think we should introduce a new version mode, e.g. EXACT_OR_MINOR
 (or any other naming you find more appropiate).

 In case this is aggreed on I would try to create a patch ASAP to be able to
 still land it in 3.1.

 Opinions?

 Eike
 --

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

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] kwsys SystemTools::RelativePath()

[David Cole via cmake-developers]

Is the result of RelativePath guaranteed to be a directory name, or is
it possibly a file name?

If a directory, then perhaps . makes sense and wouldn't negatively
impact anything (other than cosmetically) if changed. But if a file,
then . doesn't make as much sense. . to me implies it is the
current directory or the directory containing this thing depending
on the context.

D


On Fri, Oct 3, 2014 at 3:30 PM, Nils Gladitz nilsglad...@gmail.com wrote:
 On 03.10.2014 21:13, Brad King wrote:

 On 09/30/2014 10:05 AM, Nils Gladitz wrote:

 When both operands are the same absolute path I get the empty string as
 a result.

 Should it be .?

 Perhaps.  One would need to track down existing call sites
 to see where that might affect behavior.  IIRC it is exposed
 through file(RELATIVE_PATH), so it may need a policy.  That
 is probably overkill because there are legitimate use cases
 where an empty string looks better than ..


 I guess that might be a matter of definition.
 I wouldn't consider the empty string a valid path though I understand that
 this may be what people expect now given that this behavior has already been
 established.

 I've worked around the issue I had with the wix-fix-root-dir-prop topic
 for now so there is no immediate need to change behavior before the 3.1
 release.

 Thanks  for the feedback.

 Nils
 --

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

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] Support of codesign

[David Cole via cmake-developers]

Maybe it shouldn't even be a CPack thing. Maybe it should be an
install time step so that all CPack generators will contains signed
binaries if codesign is used...

D


On Mon, Sep 29, 2014 at 9:55 AM,  clin...@elemtech.com wrote:


 

 It should not be an error for 'codesign' to not be available
 in the PATH.  The user may have set CPACK_COMMAND_CODESIGN
 to some other location.  The error should only occur if no
 value for CPACK_COMMAND_CODESIGN is available when the tool
 is actually needed for signing.


 I attached another patch that will fix the broken tests. It will check for
 defined CPACK_APPLE_CERT_APP before it will search for 'codesign'.

 Well, the FindProgram line for codesign looks like the line for Rez,
 hdiutil, SetFile and so on. I don't know cmake sources enough... but
 shouldn't it be the same here?


 Because it appears to only work with the Bundle generator, can you please
 move the documentation from Modules/CPackDMG.cmake to
 Modules/CPackBundle.cmake?
 Or did you intend to make this feature work for both the DragNDrop and
 Bundle generator?

 Thanks,
 Clint

 --

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

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] [CMake] Windows rpath emulation

[David Cole via cmake-developers]

What is the problem that this feature is trying to solve?

It seems unnecessary to me as a first-class feature of CMake. I must
be missing something...

But if you do pursue something like this, it seems to me that
install(TARGETS ...) should install all files including the wrapper.

Is this only for executable files, or would something like this also
be possible/necessary for shared libraries, too?

Slicer and ParaView do (or did in the past) have similar wrappers to
set up necessary environment variables before invoking the real exe.


Thanks,
David C.


On Tue, Sep 23, 2014 at 3:05 AM, Nils Gladitz nilsglad...@gmail.com wrote:
 On 09/20/2014 11:53 PM, Nils Gladitz wrote:

 On 20.09.2014 23:31, Roland Schulz wrote:

 it would be nice if there were a way to emulate rpath under Windows.
 As far as I can see there are two possible approaches:
 - Generate a shell script which sets PATH
 - Generate a manifest for the application and a manifest for the
 dependencies.
 http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an
 example of how to do it.


 So I am thinking opt-in (target property) wrapper binaries that take the
 place of the actual binaries.

 e.g.
   # Initializes ENABLE_EXECUTABLE_WRAPPER target property
   set(CMAKE_ENABLE_EXECUTABLE_WRAPPER ON)

   add_executable(foo foo.cpp)

 Could produce
   foo.exe.real# Actual target binary
   foo.exe.wrapper # CMake generated configuration file
   foo.exe # Wrapper binary that reads foo.exe.wrapper, sets up
 the environment and runs foo.exe.real

 COMMANDs (add_custom_command()/add_custom_target()/add_test()) could
 transparently call foo.exe (like they would have done without the wrapper).

 install(TARGETS) should ignore the wrapper and transparently install and
 rename the real binary.

 $TARGET_FILE should continue to point at the real binary.
 A new $TARGET_WRAPPER could point at the wrapper binary.

 The wrapper binary itself could be precompiled and included with cmake
 itself. It would determine which configuration to read and which binary to
 run by inspecting its own name.

 I primarily had windows native builds in mind.
 Are there additional use cases?

 Nils

 --

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

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] [PATCH] FindCUDA: Wrap keyword in if() string comparison

[David Cole via cmake-developers]

I like the cmake_policy(SET CMP0053 NEW) solution, too. We should 
make a concerted effort to encourage module maintainers to do this 
before the 3.1 release for as many modules as possible.


D

--

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] What is necessary for including fixes from current development branch to official release

[David Cole via cmake-developers]

The rule is (roughly): after the first release candidate for a given
release, no more new features for that particular release. Only
continuing work to complete new features in rc1 and fixing regressions
reported from previous versions should go in subsequent release
candidates. Possible exceptions may be made for bug fixes deemed
important and broadly applicable and helpful. In the end, it's
always a judgment call, and up to the folks preparing the releases to
decide what goes in and what has to wait till next time.

As Nils said, the only stuff guaranteed to be in a release is whatever
is in 'master' already at the time the first release candidate is made.


HTH,
David C.


-- 

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] Gold standard find module?

[David Cole via cmake-developers]

I would say there are no gold standard find modules.

The gold standard is a project config file, like Qt5 has.


From http://www.cmake.org/cmake/help/v3.0/manual/cmake-qt.7.html :


the Qt 5 libraries are found using Config-file Packages shipped with 
Qt 5


Also, search this page for Config mode:

http://www.cmake.org/cmake/help/v3.0/command/find_package.html

Find modules in CMake should be the last resort option, when it is 
simply impossible to add a project config mode file to a project.


On the other hand, if the intent behind your question is to make the 
existing find modules all follow a given standard. that's quite an 
ambitious goal. Let's see if anybody else names actual names for the 
gold standard.



Just my opinion,
David C.

--

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] Gold standard find module?

[David Cole via cmake-developers]

 In this case just the one. I'm not that ambitious as I'm just
 volunteering my time to various FOSS projects and still have to
 maintain a day job to pay the bills!


:-)

In that case, I would recommend just getting it into shape so that it
works best for you. (But then, that's the way we've ended up with so
many ways of doing things in the find modules we do have) As you
submit changes for review, though, hopefully the reviewers will catch
anything that is not recommended and ask you to revise it before
pushing it into 'master'.

I think asking specific questions when you have something you're not
sure of is better than trying to identify a gold standard find module
on which to model your contributions.


HTH,
David C.



-- 

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] Alternate if() without implicit variable expansion

[David Cole via cmake-developers]

I was also thinking about setting up an alternative testing
infrastructure parallel to RunCMake which runs cmake in script mode
rather than performing configuration/generation.


This already exists in a form in the Tests/CMakeTests/*TestScript*
tests.

An example:
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/CMakeTests/StringTestScript.cmake;h=a562e71d38ff7db040e567f0ef9b899c2101bc9f;hb=ff1fddb0bf40b8a7170d54ccdc9420c2d7190472

Any *TestScript* file also requires a driving *Test.cmake.in file and 
an entry in Tests/CMakeTests/CMakeLists.txt, but the infrastructure is 
there already. Actually, there are two infrastructures in that folder, 
but this one is similar to the one you're proposing.



HTH,
David C.

--

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] Alternate if() without implicit variable expansion

[David Cole via cmake-developers]

...I would prefer to combine into something more compact.The other
infrastructure I don't think I have touched but optically it looks
very noisy.Having something that takes away repetitive tasks, more
compact and easier on the eye would be nice.


I agree. That would be nice. Feel free to reinvent and re-factor. The 
ones I put in there were added in a flurry of increasing coverage a few 
years ago.


I was just pointing it out in case you wanted to take advantage of an 
existing run-this-script pattern we already use.



Cheers,
D

--

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] Alternate if() without implicit variable expansion

[David Cole via cmake-developers]

Another approach might be to add STRING_EQUAL and STRING_MATCHES (or
similarly unambiguous names) operators that do not do the variable
lookup.

The documentation would start with:
if(string STRING_EQUAL string)
if(string STRING_MATCHES regex)
...i.e., not mentioning variable anywhere for these operators.


D


-- 

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] Changing the regex used for INFO strings

[David Cole via cmake-developers]

Looks good to me. Why not merge it to 'next' for testing? Worst case, 
you can also revert it and merge again...


D

--

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] Extracting target metadata, IDE integration

[David Cole via cmake-developers]

 Ok, how does it sound if we have a variable, such as
 CMAKE_EXPORT_COMPILE_COMMANDS?
 Let's say, CMAKE_EXPORT_TARGETS_INFORMATION.


I would prefer CMAKE_EXPORT_TARGETS_FILE, or some name that implies it
is a filename value, with the value of the variable being the name of
the file to generate.

Who's the consumer of this file? Is it just one particular IDE, or is
it meant to be general and possibly be used by multiple IDE generators?
(I'm not sure I fully understand the context of the intent here based
on the prior emails Can you explain it a little more?)


Thanks,
David C.



-- 

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] Extracting target metadata, IDE integration

[David Cole via cmake-developers]

The approach looks reasonable, but having it unconditionally spit out a 
file in cmGlobalGenerator regardless of generator is probably not what 
we want. Seems like it should be based on a variable, or be in a 
specific generator, or somehow have a limited scope.


HTH,
David C.

--

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] LZMA support

[David Cole via cmake-developers]

Wow! Fantastic!

Thanks to Daniel, great work on this contribution... This is a ton of
tedious work, but it will be very useful. Thank you *very much*.

Two minor comments -- in the commit at the tip of this topic:

http://public.kitware.com/gitweb?p=stage/cmake.git;a=commitdiff;h=5201fb2e62fb06609b02c83278da6546561a9e9f

I think the extensions should be alphabetized, and they should also
include 7z so folks can use the typically smaller 7z files with
ExternalProject as well.

Would you like me to amend and update the topic? Or would you mind
doing the minor edit for that?

BTW, I just submitted an Experimental dashboard for this topic using
ninja and the VS2012 compiler on Windows 8.1, and it was all green:
http://open.cdash.org/buildSummary.php?buildid=3420600


Thanks,
David C.

-- 

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] LZMA support

[David Cole via cmake-developers]

Thanks.  Actually I think adding xz is incorrect anyway.  We
support compressed tarballs, not arbitrary compressed files.
Therefore the list should be

  7z|bz2|tar\\.gz|tar\\.xz|tgz|txz|zip

correct?


Well, then it should be tar.bz2, too. And since this is a regex 

anyway:


   7z|tar\\.bz2|tar\\.[gx]z|t[xg]z|zip


Yes, correct.

I still like the original list all the extensions separately and 
explicitly technique rather than 'simplifying' the regex -- because 
the first one is an easier to parse as a human being regex. Also, 
it's more greppable if somebody is looking for .gz or .xz or tgz or 
txz.



D

--

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] Should try_run have a timeout value? [demo CMakeLists.txt in body of email]

[David Cole]

#
# CMakeLists.txt
#
# PROBLEM:
#
# This file demonstrates a problem with CMake 3.0 and Visual Studio
# compiler x64 builds... If configured for a build with the x64
# compiler, CMake will hang until user intervention with a
# cmTryCompileExec123...789.exe has stopped working
# crash dialog.
#
# The problem has existed forever, it's not new to CMake 3.0
#
# QUESTION:
#
#   Should try_run have a timeout value, defaulting to a few seconds (or
#   something more reasonable than NEVER) or is there a way for CMake to
#   detect this condition and kill it as an unsuccessful try_run...?
#
cmake_minimum_required(VERSION 3.0)
project(subtle_pointer_error C)

set(source_file ${CMAKE_CURRENT_BINARY_DIR}/spe.c)

file(WRITE ${source_file}.in
# OMG - long bracket argument syntax is beautiful for including
# unescaped entire other http://sscce.org/ files within a
# CMakeLists.txt!!
[=[
/*
  The problem with this code (and why it crashes on Windows x64
  builds) is malloc is used without declaring it, so the C compiler
  assumes it is extern returning int... But int is too small for a
  pointer on x64 builds, so the value that ends up in ptr is not
  the whole pointer, but only sizeof(int) bytes of it. The fix is
  obviously to include the header that declares malloc (and memcpy,
  and anything else used), but this was hard to diagnose, and
  annoying as heck on automated dashboard machines -- a failed
  try_run due to excessive attempted run time would have been a most
  welcome assist.

  Fix this problem and prove the crash goes away by adding:
#include stdlib.h
#include string.h
*/

#include stdio.h

int main(void)
{
  double value = 1234.56;
  void *ptr = malloc(sizeof(value));
  printf(before memcpy\n);
  fflush(stdout);
  memcpy(ptr, value, sizeof(value));
  printf(after memcpy\n);
  return 0;
}
]=]
)

configure_file(${source_file}.in ${source_file} COPYONLY)

try_run(
  run_result
  compile_result
  ${CMAKE_CURRENT_BINARY_DIR}/TryRun001
  ${source_file}
  COMPILE_OUTPUT_VARIABLE compile_output
  RUN_OUTPUT_VARIABLE run_output
  )

message(compile_result='${compile_result}')
message(run_result='${run_result}')
message(compile_output='${compile_output}')
message(run_output='${run_output}')

add_executable(spe ${source_file})

#
# Thanks for your opinions, and taking a look...
#
#David C.
#

-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Should try_run have a timeout value? [demo CMakeLists.txt in body of email]

[David Cole]

Would you also be satisfied if the crash dialog was disabled in the 

try_run()?

That is done for ctest by cmCTest::BlockTestErrorDiagnostics().


Sure, as long as the try_run doesn't hang, and indicates failed run 
in the run result.


I'm easy.


D

--

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Should try_run have a timeout value?

[David Cole]

 Nice literate programming!


Thank you.



-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy

[David Cole]

 Hi everybody there,

 Subject says it all. See the attached patch please.

 (Didn't care enough to leave hg for git to generate the patch. Sorry.)


FILE_PATH is likely to contain C: or some other drive letter on
Windows. It is therefore unsuitable for using to construct a sub-path
underneath CMAKE_CURRENT_BINARY_DIR.

You don't have to care enough to leave hg, but we do have to care
enough to make sure CMake still works on all the platforms it's
intended to work on.

This patch may fix your particular use case, but it is not generally
correct, and therefore, unlikely to be adopted into upstream CMake.
There must be a better solution, that will work on all platforms...


David C.


-- 

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/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] Fix error in compiling C++ files generating by protobuf compiler when .proto files are organized in a directory hierarchy

[David Cole]

Maybe I'm missing something. Is it guaranteed that all callers of 
PROTOBUF_GENERATE_CPP will pass non-full-path names for the .proto 
source files?


If so, then I retract my statement. But I don't think you can guarantee 
that.



David C.

--

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/cgi-bin/mailman/listinfo/cmake-developers