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 Ki

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  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
 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
>  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  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
>>>  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] [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
 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  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
>>  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] [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 to at least get you thinking about that irrespective of any
>> particu

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 www.kitware.com

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

Re: [cmake-developers] Question about ALIAS targets

[David Cole via cmake-developers]

>> 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.
>
> Why isn't there a standard name? Should upstream provide the imported
> target? Has any effort been made to make upstream provide it? Is the name
> from OtherProj namespaced? Why do you need it to have a particular name? Why
> does OtherProj expose it? Should it expose that target for you to use (it
> seems an internal thing to me)?
>

There is a standard name. "Upstream" in this case is a super build of
many projects, with an imported target for each project named after
the project that means "the main lib (or all the libs) in the
project". Now, for projects that already have "good imported targets"
(Qt, VTK), I don't bother creating imported targets, I allow client
projects to link directly to those imported targets. But for projects
that don't, I create a convenience imported target named after the
project.

In the case of googletest, the project name is named for its GitHub
repo, but there is no library of that name and its install provides no
imported targets. And the "main" library is just gtest. So I create an
imported target named after the project, but in this case, I also want
to create an imported target for each lib. So I do, but that means my
googletest and gtest targets are essentially identical except for
their names. ( ** i.e. aliases of each other, but both imported... **
)

I don't need it to have a particular name, but I want to follow a
chain of naming conventions: naming the project after its repo,
keeping an imported target for each project in my super build named
after the project, and then, where it makes sense, also having
per-library imported targets.

I'm not expecting anybody to do any work on this, or to loosen the
restriction for my convenience... I just wanted to know if there were
a good reason for the error message. Sounds like "nobody needed it
yet, and we were being conservative" is the answer. Which is a good
answer.


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

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

[David Cole via cmake-developers]

Last I did with it is seen here:

https://github.com/dlrdave/CMake/tree/add-targets-to-get-cmake-property?files=1

I abandoned it because of lack-of-time on my part, and the implementation is 
hacked into cmState... And I didn't have time to wade through and figure out 
what was being refactored around it at the time.

Anyone is welcome to take it and run with it...


David

> On Mar 11, 2016, at 3:58 PM, Clifford Yapp  wrote:
> 
>> On Mon, Sep 14, 2015 at 1:47 PM, Stephen Kelly  wrote:
>> Brad King wrote:
>> 
>>>> On 09/14/2015 11:46 AM, David Cole wrote:
>>>> (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...
>>> 
>>> Yes.
>> 
>> I assume you're thinking of getting the global generator from the cmake
>> instance?
>> 
>> That's not appropriate. [...]
> 
>> Making the target names available through properties via cmState is also
>> trivial after targets become first-class parts of cmState (cmState::Target
>> like cmState::Directory).
>> 
>> That can happen sooner (it's on my plate), but required refactoring is also
>> on hold until after CMake 3.4.
> 
> 
> Does anyone recall where the "list all targets" feature ended up?  Is
> it still on hold?  (I apologize if I missed any subsequent discussion
> - just now getting back to this...)
> 
> 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
-- 

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]

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

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

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]

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

> On Fri, Dec 4, 2015 at 11:32 PM, David Cole  > 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]

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  wrote:
> On Fri, Dec 4, 2015 at 9:19 PM, David Cole  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] 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  wrote:
>> 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 2:42 PM, David Cole  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]

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

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

[David Cole via cmake-developers]

I'm going to let other CMake developers chime in on this one.

It's better than the first patch, because it's opt-in, and you have to
add something to get "different than previous" behavior, but I'm still
of the opinion that this is very command specific, and you won't
always want all _DIR references as native. In my opinion, it's better
left to the person constructing the ExternalProject_Add call. But I am
curious to hear other CMake devs give their opinions.


David C.



On Tue, Aug 25, 2015 at 3:18 AM, Kislinskiy, Stefan
 wrote:
> Dear CMake developers,
>
> any thoughts on the fix? :)
>
> Best regards,
> Stefan Kislinskiy
> 
> Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
> Kislinskiy, Stefan [s.kislins...@dkfz-heidelberg.de]
> Gesendet: Freitag, 21. August 2015 23:56
> An: David Cole; James Johnston
> Cc: cmake-developers@cmake.org
> Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
> substitute for directory tokens
>
> What do you think about the new patch I attached to this mail? It adds an 
> option NATIVE_DIR_TOKENS to ExternalProjects_Add. I also attached a CMake 
> script file which tests/shows this feature.
>
> Stefan Kislinskiy
> ____
> Von: cmake-developers [cmake-developers-boun...@cmake.org] im Auftrag von 
> David Cole via cmake-developers [cmake-developers@cmake.org]
> Gesendet: Donnerstag, 20. August 2015 23:20
> An: James Johnston
> Cc: cmake-developers@cmake.org
> Betreff: Re: [cmake-developers] ExternalProject: Use native paths as 
> substitute for directory tokens
>
> 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
>  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.  etc.  It would 
>> be good if the patch updates the documentation of ExternalProject and 
>> clearly states the path format of  vs .  Then 
>> the user can pick whichever one suits them best, depending on the tool being 
>> invoked.
>>
>> Furthermore, sometimes  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 
>>  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 s

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  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
 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.  etc.  It would 
> be good if the patch updates the documentation of ExternalProject and clearly 
> states the path format of  vs .  Then the user 
> can pick whichever one suits them best, depending on the tool being invoked.
>
> Furthermore, sometimes  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 
>  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}
>  >

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.
> ) 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] [FEATURE REQUEST] ExternalProject disable all GIT_SUBMODULES

[David Cole via cmake-developers]

Isn't simply **not listing** GIT_SUBMODULES sufficient?


On Friday, August 14, 2015, Konstantin Podsvirov 
wrote:

> In the next CMake we obtain the following useful thing:
>
>
> http://www.cmake.org/cmake/help/git-master/release/dev/ExternalProject_init_selected_submodules.html
>
> But how to disable the initialization and loading of git submodules?
>
> --
> Regards,
> Konstantin Podsvirov
>
>
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Setting up environment using ExternalProject_Add

[David Cole via cmake-developers]

One thing to consider before embarking on modifying CMake for
"required environment" purposes is that it might be just as simple to
"force" (or at least strongly encourage) your project developers to
use the proper environment for running the whole build.

You could, for example, have an initial "external" project which all
others depend on which verifies the proper environment is set when it
is called. If not, it fails with an error, and prevents downstream
bits from building.

Such a project would have to *always* be called, whenever *any* build
step is executed, but if all it does is verify proper environment
settings, it should not slow your build down at all.

I have such a project I'm working on, and it works fairly well. If you
run it outside the expected env, it fails quickly with an informative
error, explaining how to run it in the proper env. Unfortunately, it's
private, so I can't share a link to it, but the idea is a sound
approach, without any complicating changes to CMake.


HTH,
David C.



On Wed, Aug 12, 2015 at 10:10 AM, Brad King  wrote:
> On 08/11/2015 10:41 AM, James Johnston wrote:
>> 1.  CMake creates a temporary shell script / batch file (the shell chosen
>> based on the platform CMake compiled for - cmd.exe on Windows, sh on POSIX).
>
> I don't think CMake needs to be the one to generate this.  The complexity
> of the file-based or command-line-based interfaces you discussed shows
> that it would be tricky to have CMake generate it.
>
>> Users would be required to provide scripts for environment setup in the
>> format of the native shell
>
> For this projects would need to spell out platform-specific code anyway
> so there is no point in trying to abstract that part away.
>
>> 3. Then CMake runs the above script as normal and checks the exit code
>
> I don't think CMake actually has to be in the middle here.  The generated
> build system could reference the script directly.
>
>> enhancing e.g. add_custom_command as I proposed might make it easier,
>> as this command could be aware of compiled EXE targets.
>
> With file(GENERATE) the project code can easily create scripts that
> reference executable targets and such.  One would just need to tackle
> this feature request first to get file permissions right:
>
>  http://www.cmake.org/Bug/view.php?id=15653
>
> Therefore I do not think add_custom_command needs any hook for this.
> One would simply give the script as the COMMAND.
>
>> we'd want to add features to ExternalProject that use the new CMake
>> functionality to finally solve the original problem.
>
> Yes, this part certainly needs an update to ExternalProject.  Currently
> when one specifies an individual _COMMAND like CONFIGURE_COMMAND,
> then one could simply give it the environment-set-and-launch script
> directly.  What ExternalProject needs is an interface to specify the
> environment-setting script for use around otherwise default-generated
> commands for each step.  For example, a _ENVIRONMENT setting
> (which is perhaps not allowed in combination with _COMMAND).
> This approach is similar to your original alternative (3).
>
> 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]

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

On Mon, Jul 20, 2015 at 9:30 AM, Brad King  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  wrote:

> On Fri, Jul 17, 2015 at 6:05 PM, David Cole  > 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]

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

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

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

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  wrote:
> On Wed, Jul 15, 2015 at 9:10 AM, Brad King  wrote:
>> On 07/10/2015 03:42 PM, Clifford Yapp wrote:
>>> On Thu, Jul 9, 2015 at 1:35 PM, Clifford Yapp  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
 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  
> 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 " 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  
>> 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
 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 " 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  
> 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 " 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
 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  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
 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
>  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  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  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] 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  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] 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  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]

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

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  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=331119724&build=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
>  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 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=331119724&build=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
 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
 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  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
>>  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
>>> CM

Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add

[David Cole via cmake-developers]

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

Great -- thanks for checking. This proposed change looks reasonable to me...

On Fri, Apr 17, 2015 at 12:27 PM, Andrey Pokrovskiy
 wrote:
>> does the external project's configure step re-run when you edit only the 
>> CMAKE_CACHE_ARGS for it?
>
> Yes. Verified with the following example:
>
> 
> cmake_minimum_required(VERSION 3.2)
>
> project(CMakeExternalProjectGenExpr)
>
> include(ExternalProject)
>
> set(ZF_QUEUE_INSTALL_PREFIX "${CMAKE_CURRENT_BINARY_DIR}/zf_queue.install")
>
> ExternalProject_Add(zf_queue_ep
> GIT_REPOSITORY https://github.com/wonder-mice/zf_queue.git
> UPDATE_COMMAND ""
> INSTALL_DIR ${ZF_QUEUE_INSTALL_PREFIX}
> CMAKE_CACHE_ARGS
> -DCMAKE_INSTALL_PREFIX:string=)
>
> On Fri, Apr 17, 2015 at 4:19 AM, David Cole  wrote:
>> 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
>>  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 $)
>>> 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] 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
 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 $)
> 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  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  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 
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] [vc12/idl] output directory problem

[David Cole via cmake-developers]

If this change fixes the problem... then the problem must be that the
midl tool is being run from the wrong directory when it fails. Or that
midl is being run at the same time for two different projects both
trying to write output into the same directory simultaneously? (But
wouldn't this latter one *still* be a problem with this fix?)

I hate mysteries.




On Mon, Feb 23, 2015 at 1:32 PM, Brad King  wrote:
> On 02/21/2015 07:58 AM, Tim Blechmann wrote:
>> i'd love to provide a reduced test case, though i can only reproduce
>> this in a complex real-world buildsystem, with dozens of libraries and
>> some include_external_msproject / add_dependencies pairs ...
> [snip]
>> that said, i wonder: why would it be ok to use a relative path in the
>> generated project ... or, what would be the disadvantage of using an
>> absolute path?
>
> I don't think that is a problem.  I was just hoping to add a test case.
> At least the existing test case should not be regressed by the change.
> Applied:
>
>  VS: Specify absolute output directory for the Midl tool
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0b54e836
>
> 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] 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  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
 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  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  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  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  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  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] Recent GetPrerequisites changes

[David Cole via cmake-developers]

On Mon, Nov 24, 2014 at 3:10 PM, Rolf Eike Beer  wrote:
> David Cole wrote:
>> Eike,
>>
>> The changes you made in this commit:
>>
>> http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec36e1c2afe7c8258588d
>> d51a9fe75b7fb523206
>>
>> appear to have introduced a change in behavior such that the test is
>> running recursive dependency checks instead of just direct dependency
>> checks.
>>
>> Evidence:
>> 11/18: test passed in under 3 seconds:
>> http://open.cdash.org/testDetails.php?test=294732956&build=3575799
>> updates: http://open.cdash.org/viewUpdate.php?buildid=3577230
>> 11/19: test fails, times out after 10 minutes:
>> http://open.cdash.org/testDetails.php?test=294964093&build=3577230
>>
>> I think the root of the problem is the tests for ARGV1, ARGV2, etc.
>> that you made are not equivalent to the previous code in the case of a
>> nested function call: (a function calling a function ... or deeper --
>> weird stuff happens if you call a function with fewer than its
>> declared arguments -- i.e. there is no ARGV2 variable within a
>> function called with only one argument, but there may be in the parent
>> scope if it's called from a function that does get called with 2 or
>> more args)
>
> I remember slightly that there once was a discussion about something like
> that. Sounds creepy.
>

Yes it does. I should figure it out this time and write it down somewhere...

And then fix it, but probably with a policy to preserve the subtle old
behavior for a while. Not sure I'll have time to tackle it any time
soon.

>> So some of the "needless" variable dereferencing you removed is
>> actually needed.
>>
>> Would you mind reverting those commits, or modifying them such that
>> the new behavior is identical to the older behavior, please?
>
> Sure.
>

Thanks a bunch.

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] Recent GetPrerequisites changes

[David Cole via cmake-developers]

Eike,

The changes you made in this commit:

http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ec36e1c2afe7c8258588dd51a9fe75b7fb523206

appear to have introduced a change in behavior such that the test is
running recursive dependency checks instead of just direct dependency
checks.

Evidence:
11/18: test passed in under 3 seconds:
http://open.cdash.org/testDetails.php?test=294732956&build=3575799
updates: http://open.cdash.org/viewUpdate.php?buildid=3577230
11/19: test fails, times out after 10 minutes:
http://open.cdash.org/testDetails.php?test=294964093&build=3577230

I think the root of the problem is the tests for ARGV1, ARGV2, etc.
that you made are not equivalent to the previous code in the case of a
nested function call: (a function calling a function ... or deeper --
weird stuff happens if you call a function with fewer than its
declared arguments -- i.e. there is no ARGV2 variable within a
function called with only one argument, but there may be in the parent
scope if it's called from a function that does get called with 2 or
more args)

So some of the "needless" variable dereferencing you removed is
actually needed.

Would you mind reverting those commits, or modifying them such that
the new behavior is identical to the older behavior, please?


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]

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  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
>  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 
>>  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] 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
 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 
>  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  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 was hoping you'd say that! :-)

On Fri, Nov 14, 2014 at 12:23 PM, Gilles Khouzam
 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?onlyfailed&buildid=3570369
http://open.cdash.org/viewTest.php?onlyfailed&buildid=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] 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,  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 -m"init"
> > 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=CMake&date=2014-07-09

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

On Thu, Nov 6, 2014 at 5:27 PM, Rolf Eike Beer  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] [Review request] Topic ExternalProject_SCM_DISCONNECTED

[David Cole via cmake-developers]

I would prefer a name that begins with UPDATE_ if it only affects the
update step.

D


On Wed, Nov 5, 2014 at 6:57 PM, Daniele E. Domenichelli <
daniele.domeniche...@gmail.com> wrote:

> On 05/11/14 17:39, Brad King wrote:
> > Would the name "UPDATE_INDEPENDENT" or "UPDATE_DISCONNECTED"
> > make more sense?  Otherwise, the topic looks ready for testing
> > to me.
>
> "UPDATE_INDEPENDENT" might be confused with something related to
> "INDEPENDENT_STEP_TARGETS", so I'd rather choose between
> SCM_DISCONNECTED or UPDATE_DISCONNECTED... Both work for me.
>
> Let me know if I should rename it or if I should merge it to next.
>
> Cheers,
>  Daniele
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
-- 

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

> 2014-10-27 21:33 GMT+01:00 Ben Boeckel :
>
>> 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
 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  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  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] 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  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] 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  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] 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,   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  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.
>
> $ should continue to point at the real binary.
> A new $ 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] 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] [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] 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] 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] 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]

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