Re: [cmake-developers] [CDT] Improving CDT4 generator

On 2019 M03 20, Wed 13:53:49 CET Brad King via cmake-developers wrote: > On 3/19/19 4:57 PM, David wrote: > > since Eclipse 9.2 (or 9.1 do not remember), the CMake CDT4 Generator > > does not work as expected for C++ Project. > > > > What is the best way to propose an update ? > > Please see

Re: [cmake-developers] Fwd: [CMake] link only with targets feature

On 2019 M02 12, Tue 08:34:57 CET Timothy Wrona wrote: > I saw this email come through the cmake users mailing list but feel it is > more fitting for it to go to cmake-developers so I'm forwarding it here. > > It is a pretty long rant, but I think his idea to add a keyword to the >

Re: [cmake-developers] CMake Cache Library

On 2018 M11 12, Mon 17:53:38 CET Taylor Holberton wrote: > Hello everyone! > > Today I released a short and sweet C++ library for accessing and modifying > CMake Cache files. > > Feel free to use it, critique it, or ignore it entirely. > > You can find it on GitHub, at

Re: [cmake-developers] How to handle dependencies of protobuf files ?

Hi, On 2018 M05 29, Tue 09:52:16 CEST Brad King wrote: > On 05/15/2018 03:45 PM, Alexander Neundorf wrote: > > I think to do it properly, there would have to be a dependency scanning > > for > > proto files like there is for C/C++ headers. > > In order to handle

Re: [cmake-developers] How to handle dependencies of protobuf files ?

Any comments ? Alex On 2018 M05 15, Tue 21:45:06 CEST Alexander Neundorf wrote: > Hi, > > I stumbled upon a problem with protobuf files, I attached a testcase. > There is a MyBase.proto, which is "imported" by Complex.proto. > If MyBase.proto is modified, protoc is

[cmake-developers] How to handle dependencies of protobuf files ?

Hi, I stumbled upon a problem with protobuf files, I attached a testcase. There is a MyBase.proto, which is "imported" by Complex.proto. If MyBase.proto is modified, protoc is run again in MyBase.proto, but not on Complex.proto, although it should. You can have a look at the attached example.

Re: [cmake-developers] new generator question - xml file output for embedded IDE platforms.

On 2018 M05 2, Wed 09:17:53 CEST du...@duaneellis.com wrote: > >> configure_file is not the right command > > Yea, it's the nearest existing item, and it only does the most > simplistic replacement that's why I use that as a basis for my example. > It is in effect, like the final last 'sed' step

Re: [cmake-developers] Adding a non-make based generator

Hi, On 2018 M02 14, Wed 22:16:54 CEST Alexander Neundorf wrote: > On 2018 M02 14, Wed 18:46:52 CET Saeed, Khurram wrote: > > Thanks Alex. > > Yes it does support generating the project in the build dir. It also works > > while generating in a subdir of the source dir. Ec

Re: [cmake-developers] Adding a non-make based generator

On 2018 M02 14, Wed 18:46:52 CET Saeed, Khurram wrote: > Thanks Alex. > Yes it does support generating the project in the build dir. It also works > while generating in a subdir of the source dir. Eclipse version control > plugin also works (I am using git). Interesting. How did you get that

Re: [cmake-developers] Adding a non-make based generator

Hi, On 2018 M02 9, Fri 13:16:19 CET Saeed, Khurram wrote: > Hi Alex, > > I have not made it available anywhere so far. Although my target while > writing this generator was only to make it work for ReadyStart projects. > However, I think with some effort down the road it might be possible to use

Re: [cmake-developers] Adding a non-make based generator

Hi Kurram, On 2018 M02 7, Wed 12:09:54 CET Saeed, Khurram wrote: > Hi Neundorf, > This generator can only be used for generating Nucleus ReadyStart IDE > projects. It generates Eclipse CDT project files that use ReadyStart > specific plugins and configurations. I have the impression Brad was not

Re: [cmake-developers] Adding a non-make based generator

Hi Saeed, On 2018 M02 2, Fri 15:05:19 CET Saeed, Khurram wrote: > Hi, > Nucleus > ReadyStart is > an eclipse based IDE by Mentor Embedded(tm). > It is used for creating and building C/C++ based Nucleus >

Re: [cmake-developers] kwsysProcess threadsafety

On 2018 M01 8, Mon 10:32:22 CET Jean-Michaël Celerier wrote: > > 3) Abandon the idea to parallelize AUTOMOC/UIC > > please no ! moc is a huge bottleneck in my builds (to the point that using > verdigris instead ends up having > faster build time overall). you

Re: [cmake-developers] Antwort: Re: Non supported toolchain

On 2017 M11 23, Thu 07:22:19 CET oliver.za...@egoproducts.com wrote: > Hi Alex, > > thanks for your answer. > 1. is there some guide or at least some example? > 2. Does this module needs to be in the offical build to be distributed or > is there a possibility to distribute the modules locally?

Re: [cmake-developers] Non supported toolchain

On 2017 M11 22, Wed 10:37:00 CET oliver.za...@egoproducts.com wrote: > Hi, > > i know this is the dev mailing list, but i tried to solve my problem in > the normal one (see here > https://www.mail-archive.com/cmake@cmake.org/msg57862.html) with no > success. > > In Short: i have a toolchain for

Re: [cmake-developers] Native Compilers

On 2017 M09 26, Tue 16:21:21 CEST Kevin Funk wrote: > On Monday, 25 September 2017 20:39:01 CEST Ivam Pretti wrote: > > When you use cmake-gui, below the button configure there is an option to > > choose the compiler. This compilers are alredy intalled with cmake or it > > needs to install

Re: [cmake-developers] Feature suggestion: auto-create missing files

On 2017 M04 11, Tue 11:52:52 CEST Brad King wrote: > On 04/11/2017 11:41 AM, Petr Kmoch wrote: > > Currently, adding a new source file to a CMake-controlled project > > means doing two things: creating the file on disk, and adding it > > to the relevant CMakeList add_library() or add_executable()

Re: [cmake-developers] Eclipse CDT Managed build

On 2017 M01 25, Wed 11:38:06 CET Brad King wrote: > On 01/25/2017 11:27 AM, Ben Boeckel wrote: > > not be trivial to get CMake to generate relocatable builds. > > This is also an explicit non-goal of CMake. > > >> after CMake generation the project can be configured through the IDE UI. > > That

Re: [cmake-developers] [Discussion] Down with discrimination CPack!

On 2017 M01 18, Wed 22:20:14 CET Konstantin Podsvirov wrote: > What about add to CMake language new packaging problematic scopes: > > - COMPONENT; > - COMPONENT_GROUP; > - PACKAGE; > - INSTALLER; > - REPOSITORY? that's a quite terse proposal... Alex -- Powered by www.kitware.com Please

Re: [cmake-developers] daemon-mode: Project structure

On Thursday 09 June 2016 12:59:40 Tobias Hunger wrote: > Hi Milian, ... > > > "targets": > > > [ > > > { > > > "fullName":"test", > > > "name":"test", > > > "type":"GLOBAL_TARGET" > > > }, > > > > > > A

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

On Monday, February 22, 2016 22:30:42 Stephen Kelly wrote: > Jean-Michaël Celerier wrote: > > There is also https://www.cevelop.com/ which is an Eclipse derivative, > > they may be interested ? > > I went all hipster reach-out.io and tweeted at them. :) looks like that's an FP7-project, so I

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

On Friday, February 19, 2016 11:36:35 Stephen Kelly wrote: > Alexander Neundorf wrote: > > On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote: > >> On 02/15/2016 07:24 PM, Tobias Hunger wrote: > >> > Hi Dominik, > >> > > >> > Am 15

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote: > On 02/15/2016 07:24 PM, Tobias Hunger wrote: > > Hi Dominik, > > > > Am 15.02.2016 19:01 schrieb "Dominik Haumann" > > > >: > > > 1. Wouldn't it make sense you have a developer sprint

Re: [cmake-developers] [PATCH]: CodeBlocks: improve support for different compilers

On Tuesday, February 16, 2016 10:49:24 Brad King wrote: > On 02/12/2016 03:24 AM, melven.roehrig-zoell...@dlr.de wrote: > > Just a small patch for the CodeBlocks generator > > Thanks! Applied: > > CodeBlocks: improve support for different compilers >

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

On Thursday, January 14, 2016 21:31:51 Kevin Funk wrote: > On Wednesday, January 13, 2016 10:16:44 PM Alexander Neundorf wrote: > > On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote: > > > Running version 3.2.2 on Ubuntu 15. I run the following command: > >

Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote: > Running version 3.2.2 on Ubuntu 15. I run the following command: > > $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9 > -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config >

Re: [cmake-developers] CMake alternative language

On Wednesday, January 13, 2016 10:59:39 yann suisini wrote: > Hi, > > I'm a new user of CMake, but I just want to express my newcomer point of > view. > Honestly , I can feel the power of CMAKE, but it's a real pain to learn ... > I'm using CMAKE for an embedded platform with a non GNU compiler ,

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

he generator approach we discussed a year ago > > and explicitly says he won't work on that, so nothing will happen > > there. > > The generate-json-description approach remains a valid alternative. > Aleix's work on it got pretty far before Stephen proposed the daemon > alternative.

Re: [cmake-developers] CMake daemon for user tools

On Tuesday, January 12, 2016 23:20:14 Milian Wolff wrote: > On Montag, 11. Januar 2016 23:22:23 CET Alexander Neundorf wrote: ... > > Stephens big approach will need some time until it is ready, while such a > > (relatively) simple thing can probably be done within one release c

Re: [cmake-developers] CMake daemon for user tools

On Monday, January 11, 2016 15:59:35 Aleix Pol wrote: ... > > Hi Stephen, everyone, > I've already discussed this in private with you. I think it's a good > idea and I'd like to make sure we can benefit from this. > > I'm unsure of the feasibility of the project though. you maybe remember that

[cmake-developers] (Experimental) Refactored extra-generators

Hi, I spent a few hours on the extra-generators, and you can find the result here on github: https://github.com/neundorf/CMake/tree/RefactorExtraGeneratorsExperimental In this branch, the extra-generators are not tied anymore hardcoded to the generators (so the generator list is short again),

Re: [cmake-developers] Profile Cmake scripts

On Sunday, December 27, 2015 18:40:27 Dimitar Yordanov wrote: > Hi all, > > I was searching for a way to profile CMake scripts in order to find > bottlenecks and possibilities to improve performance. I found out that > someone already invested time on that [1] providing a minimal solution. The >

Re: [cmake-developers] [PATCH] CMakeParseArguments: Test suite and native implementation

On Thursday, December 17, 2015 11:12:22 Brad King wrote: > On 12/14/2015 04:52 PM, Matthias Männich wrote: > > This adds a test suite for the CMakeParseArguments module. In addition > > the second change implements cmake_parse_arguments(...) as native > > command. > > Thanks! Applied with

Re: [cmake-developers] set(CACHE) and the local scope

On Friday, December 11, 2015 14:44:39 Ben Boeckel wrote: ... > Option 3: > > set(CACHE) (and any other cache-touching behavior) does *nothing* > with the cache if a local variable by that name is defined just to clarify: and also does nothing to the local variable ? Alex -- Powered

Re: [cmake-developers] set(CACHE) and the local scope

On Wednesday, December 09, 2015 17:35:28 Ben Boeckel wrote: > Hi, > > So some behavior I was unaware of until today came up: > > set(var ON) > option(var "description" OFF) > message("var: ${var}") Assuming I wouldn't know about the subtle characteristics of normal vs. cache

Re: [cmake-developers] set(CACHE) and the local scope

On Thursday, December 10, 2015 15:26:54 Brad King wrote: > On 12/10/2015 03:20 PM, Alexander Neundorf wrote: > >> set(var ON) > >> option(var "description" OFF) > >> message("var: ${var}") > > > > I.e. on the first run it would be O

Re: [cmake-developers] Generating buildsystem metadata from CMake

Hi, On Saturday, July 25, 2015 20:33:46 Stephen Kelly wrote: > Aleix Pol wrote: > > On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly > > > > wrote: > >> Stephen Kelly wrote: > >>> The aim is to generate a structured file containing metadata relating > >>> the buildsystem. >

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

On Thursday, September 10, 2015 16:02:23 Konstantin Podsvirov wrote: > The first 100 views! > The interest is there (though not great), but where are the questions and > suggestions? the web page is quite short on details... It's not an IDE, is it a set of scripts ? Alex -- Powered by

Re: [cmake-developers] A policy for Policies

On Saturday, June 20, 2015 11:29:46 Stephen Kelly wrote: Brad King wrote: snip I recommend the following guidelines: 1) Policies need to result in errors in a short timeframe. They are not something to ignore for years, because allowing that makes them feature toggles. Alex won't be

Re: [cmake-developers] A policy for Policies

On Monday, June 08, 2015 09:57:14 Brad King wrote: ... This may be okay for CMP0011, but CMP0024 and CMP0026 were much more recent (3.0). I think 5 years is a more reasonable cut-off than 2 years, especially given the time it takes CMake versions included in older distro releases to fall out

Re: [cmake-developers] Extracting target metadata, IDE integration

On Sunday, March 15, 2015 18:00:25 Nils Gladitz wrote: On 15.03.2015 16:42, Tobias Hunger wrote: Hi Peter, CMake does know all the headers or it could not decide which files need rebuilding. The build system that CMake generates knows the header dependencies and decides when which

Re: [cmake-developers] Extracting target metadata, IDE integration

On Saturday, March 14, 2015 09:40:41 Peter Kümmel wrote: On 12.03.2015 16:24, Tobias Hunger wrote: A list of *all* headers used during the building of the target would be fine. There is no need to filter that list down in any way. CMake has that information: Without it cmake could not

Re: [cmake-developers] Generating buildsystem metadata from CMake

On Wednesday, March 11, 2015 11:10:30 Stephen Kelly wrote: Hi, Following from the thread here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu s=12394 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu s=12650 I'm starting to

Re: [cmake-developers] Extracting target metadata, IDE integration

On Monday, February 16, 2015 21:31:45 Aleix Pol wrote: On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly steve...@gmail.com wrote: Aleix Pol wrote: Hi guys, It's been since August with this. I understand we're all busy but this step is important for KDevelop as well as for other IDE's and I

Re: [cmake-developers] Extracting target metadata, IDE integration

On Tuesday, December 23, 2014 01:30:58 Aleix Pol wrote: On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev ... * No progress indication. Since the generation may take several minutes, providing feedback is crucial. I never found such case, I would argue that a project which has a cmake

Re: [cmake-developers] Was AUTOMOC designed to run for each build?

On Friday, September 26, 2014 01:53:35 Stephen Kelly wrote: Alexander Neundorf wrote: I don't see why the target is executed each time, but is it that way by design? iirc, yes. The moc files have to be generated before any of the source files is compiled, so automoc is in a target

Re: [cmake-developers] Extracting target metadata, IDE integration

On Thursday, September 25, 2014 07:14:38 Anton Makeev wrote: ... Here is why I think the discussed functionality should not be a separate generator: CLion doesn’t have it’s own project model nor is intended as build tool replacement. Currently, the only option for CLion users is makefiles

Re: [cmake-developers] Was AUTOMOC designed to run for each build?

On Tuesday, September 23, 2014 09:58:58 Stephen Kelly wrote: Hi (especially Alex), I noticed that the automoc target is run each time, even for a trivial project: cmake_minimum_required(VERSION 2.8) project(automoctest) set(CMAKE_AUTOMOC ON) find_package(Qt5Widgets REQUIRED)

Re: [cmake-developers] Extracting target metadata, IDE integration

On Friday, September 19, 2014 21:53:40 Alexander Neundorf wrote: On Friday, September 19, 2014 13:44:45 Brad King wrote: ... * Don't IDEs want to know the list of source files so they can be used for editing? I haven't looked at what the Extra generators produce in a while

Re: [cmake-developers] Extracting target metadata, IDE integration

On Friday, September 19, 2014 13:44:45 Brad King wrote: ... * Don't IDEs want to know the list of source files so they can be used for editing? I haven't looked at what the Extra generators produce in a while but since they are meant for IDEs they would be a good reference for the

Re: [cmake-developers] Gold standard find module?

On Wednesday, September 10, 2014 10:38:44 Richard Shaw wrote: On Wed, Sep 10, 2014 at 7:18 AM, David Cole dlrd...@aol.com wrote: 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

Re: [cmake-developers] Extracting target metadata, IDE integration

On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote: On Tue, Sep 2, 2014 at 3:58 PM, David Cole dlrd...@aol.com wrote: It makes sense. But what IDE are you referring to? Eclipse? Some other concrete example? Or just any IDE and this feature should work everywhere CMake works...?

Re: [cmake-developers] Extracting target metadata, IDE integration

On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers wrote: It makes sense. But what IDE are you referring to? Eclipse? Some other concrete example? Or just any IDE and this feature should work everywhere CMake works...? AFAIK it is kdevelop4, and the goal is that developers

Re: [cmake-developers] Extracting target metadata, IDE integration

On Monday, September 01, 2014 15:26:12 David Cole via cmake-developers wrote: The approach looks reasonable, but having it unconditionally spit out a file in cmGlobalGenerator regardless of generator is probably not what we want. Seems like it should be based on a variable, or be in a specific

Re: [cmake-developers] find_package() verbosity

On Tuesday, August 26, 2014 10:41:04 Nils Gladitz wrote: Are there any official recommendations or opinions on how verbose a find module (or package configuration file) should be on success? - Find modules using FindPackageHandleStandardArgs report success once. - FindBoost.cmake reports

Re: [cmake-developers] What about #line like feature in cmake language?

On Thursday, May 22, 2014 09:16:17 Brad King wrote: On 05/21/2014 04:05 PM, Nicolas Desprès wrote: at the time the AST node is created the file location is frozen. Locations are controlled by the lexer so do comments. Correct. This has to be done by the lexer. We already have

Re: [cmake-developers] dpkg-shlibdeps

On Monday, May 19, 2014 13:06:17 Kornel Benko wrote: Am Montag, 19. Mai 2014 um 12:59:31, schrieb Nils Gladitz nilsglad...@gmail.com On 05/19/2014 12:50 PM, Kornel Benko wrote: I am using CPACK with set(CPACK_DEBIAN_PACKAGE_DEBUG ON) There is one offending output

Re: [cmake-developers] CMP0043 warnings everywhere

On Monday, April 28, 2014 10:26:56 James Bigler wrote: -Original Message- From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Brad King Sent: Wednesday, April 23, 2014 11:06 AM To: cmake-developers@cmake.org Subject: Re: [cmake-developers] CMP0043

Re: [cmake-developers] CMP0043 warnings everywhere

On Monday, April 28, 2014 13:39:09 Brad King wrote: On 04/28/2014 01:26 PM, James Bigler wrote: I thought the purpose of policies was to keep some backward compatibility feature, but allow users to select the new behavior. The purpose is to change CMake interfaces or behavior while still

Re: [cmake-developers] cmake --find-package

On Friday, April 25, 2014 12:10:30 Alan W. Irwin wrote: On 2014-04-24 22:41+0200 Alexander Neundorf wrote: On Wednesday, April 23, 2014 14:45:45 Alan W. Irwin wrote: On 2014-04-23 22:40+0200 Alexander Neundorf wrote: On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote: On 2014-04-23

Re: [cmake-developers] cmake --find-package

On Wednesday, April 23, 2014 14:45:45 Alan W. Irwin wrote: On 2014-04-23 22:40+0200 Alexander Neundorf wrote: On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote: On 2014-04-23 13:21-0400 Bill Hoffman wrote: On 4/23/2014 12:22 PM, Alan W. Irwin wrote: However, if you discover

Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)

On Wednesday, April 23, 2014 09:22:09 Alan W. Irwin wrote: On 2013-10-19 20:16+0200 Alexander Neundorf wrote: On Thursday 17 October 2013, Stephen Kelly wrote: Brad King wrote: On 10/17/2013 04:58 PM, Alexander Neundorf wrote: Yes, that was the idea, but I can't rely anymore

Re: [cmake-developers] cmake --find-package

On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote: On 2014-04-23 13:21-0400 Bill Hoffman wrote: On 4/23/2014 12:22 PM, Alan W. Irwin wrote: However, if you discover the problem is a general one for --find-package and Qt5, then it appears that Qt5 might be a good illustrative

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

On Friday, February 21, 2014 14:32:18 Brad King wrote: On 02/21/2014 02:18 PM, Jean-Christophe Fillion-Robin wrote: If possible, not having implicit expansion for quoted argument would be great at make things more intuitive and practical. This has been discussed before. It will take some

Re: [cmake-developers] Request for review of topic intel-visibility

On Friday, February 07, 2014 05:33:47 PM Stephen Kelly wrote: Nils Gladitz wrote: On 02/07/2014 04:24 PM, Brad King wrote: This looks correct to me and is a good bug fix. Please merge to 'next' for testing. Thanks, will do! Do you have access to Intel C/C++ on OS X that you could

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

On Tuesday 28 January 2014, Brad King wrote: On 01/23/2014 04:08 PM, Alexander Neundorf wrote: Any more comments left ? Moving the discussion from http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9156/focu s=9158 back to the thread where it belongs: On 01/27/2014

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

On Monday 06 January 2014, Alexander Neundorf wrote: Hi, on cmake stage I have a simple branch AddVersionToProjectCommand. This extends the project command to also accept a version number: project(Foo VERSION 1.2.3 CXX) All that does is setting some more variables (beside PROJECT_NAME

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

On Tuesday 21 January 2014, Stephen Kelly wrote: Alexander Neundorf wrote: On Sunday 19 January 2014, Stephen Kelly wrote: Alexander Neundorf wrote: This is now in the AddVersionToProjectCommand branch on git stage. Please have a close look at it. The documentation

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

On Sunday 19 January 2014, Stephen Kelly wrote: Alexander Neundorf wrote: This is now in the AddVersionToProjectCommand branch on git stage. Please have a close look at it. The documentation is not formatted correctly as rst. I looked at the generated html file, it seemed to look ok

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

On Wednesday 15 January 2014, Matthew Woehlke wrote: On 2014-01-15 16:25, Alexander Neundorf wrote: On Wednesday 15 January 2014, Alexander Neundorf wrote: And, to actually produce the breakage, at some place the VERSION argument must have been added. With the current state of my branch

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

On Sunday 19 January 2014, Alexander Neundorf wrote: On Wednesday 15 January 2014, Matthew Woehlke wrote: On 2014-01-15 16:25, Alexander Neundorf wrote: On Wednesday 15 January 2014, Alexander Neundorf wrote: And, to actually produce the breakage, at some place the VERSION argument

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

On Wednesday 15 January 2014, Matthew Woehlke wrote: On 2014-01-14 18:00, Alexander Neundorf wrote: On Tuesday 14 January 2014, Matthew Woehlke wrote: While that sounds good for 99.9% of cases, what about the case of project A that includes project B, where B is not updated, but A decides

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

On Wednesday 15 January 2014, Alexander Neundorf wrote: On Wednesday 15 January 2014, Matthew Woehlke wrote: On 2014-01-14 18:00, Alexander Neundorf wrote: On Tuesday 14 January 2014, Matthew Woehlke wrote: While that sounds good for 99.9% of cases, what about the case of project

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

On Tuesday 14 January 2014, Brad King wrote: On 01/13/2014 01:38 PM, Alexander Neundorf wrote: does this require a policy now ? Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a project(Foo) call in a subdir, which would now unset Foo_VERSION_MAJOR. The same

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

On Tuesday 14 January 2014, Matthew Woehlke wrote: On 2014-01-14 10:37, Brad King wrote: On 01/13/2014 01:38 PM, Alexander Neundorf wrote: does this require a policy now ? Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a project(Foo) call in a subdir, which

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

On Friday 10 January 2014, Alexander Neundorf wrote: On Friday 10 January 2014, Brad King wrote: On 01/06/2014 04:41 PM, Alexander Neundorf wrote: I modified write_basic_package_version_file() accordingly, so that you can now simply do project(Foo VERSION 1.2.3

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

On Friday 10 January 2014, Matthew Woehlke wrote: On 2014-01-10 11:01, Jean-Christophe Fillion-Robin wrote: Would it make sense to have project(Foo VERSION 1.2.3) set the variables: ${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK) That way, the variable would remain even if

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

On Friday 10 January 2014, Brad King wrote: On 01/06/2014 04:41 PM, Alexander Neundorf wrote: I modified write_basic_package_version_file() accordingly, so that you can now simply do project(Foo VERSION 1.2.3) ... write_basic_package_version_file(FooConfigVersion.cmake

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

On Friday 10 January 2014, Alexander Neundorf wrote: On Friday 10 January 2014, Brad King wrote: On 01/06/2014 04:41 PM, Alexander Neundorf wrote: I modified write_basic_package_version_file() accordingly, so that you can now simply do project(Foo VERSION 1.2.3

Re: [cmake-developers] Generators and Extra Generators

On Wednesday 08 January 2014, Stephen Kelly wrote: Alexander Neundorf wrote: On Tuesday 07 January 2014, Stephen Kelly wrote: Is there a design issue here? I run cmake-gui and select the one I want from a list. What is the problem, the length of the list ? More the combinatorial

Re: [cmake-developers] Generators and Extra Generators

On Tuesday 07 January 2014, Stephen Kelly wrote: David Cole wrote: There's been a design issue since extra generators were introduced... The question is: is it possible to resolve it with a better design and still keep the existing functionality? Hence this mail :), and my mail to

Re: [cmake-developers] cmake --help-custom-modules compatibility

On Wednesday 08 January 2014, you wrote: On 11/20/2013 07:22 PM, Stephen Kelly wrote: The solution is still to re-implement the --help-custom-modules myman.1 command-line behavior as a special case with warnings. Alex and Steve will have to work out who takes responsibility for that.

Re: [cmake-developers] Generators and Extra Generators

On Tuesday 07 January 2014, Stephen Kelly wrote: Hi, With the addition of the Kate Project stuff, we got 4 new generators rather than a single option to generate the information needed by Kate in a generator independent way, similar to CMAKE_EXPORT_COMPILE_COMMANDS.

Re: [cmake-developers] Generators and Extra Generators

On Tuesday 07 January 2014, Stephen Kelly wrote: David Cole wrote: There's been a design issue since extra generators were introduced... The question is: is it possible to resolve it with a better design and still keep the existing functionality? Hence this mail :), and my mail to

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

On Monday 06 January 2014, Rolf Eike Beer wrote: Am Montag, 6. Januar 2014, 23:26:49 schrieb Alexander Neundorf: On Monday 06 January 2014, Rolf Eike Beer wrote: Am Montag, 6. Januar 2014, 22:41:26 schrieb Alexander Neundorf: Hi, on cmake stage I have a simple branch

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

Hi, on cmake stage I have a simple branch AddVersionToProjectCommand. This extends the project command to also accept a version number: project(Foo VERSION 1.2.3 CXX) All that does is setting some more variables (beside PROJECT_NAME, PROJECT_SOURCE_DIR, PROJECT_BINARY_DIR and the

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

On Monday 06 January 2014, Rolf Eike Beer wrote: Am Montag, 6. Januar 2014, 22:41:26 schrieb Alexander Neundorf: Hi, on cmake stage I have a simple branch AddVersionToProjectCommand. This extends the project command to also accept a version number: project(Foo VERSION 1.2.3 CXX

Re: [cmake-developers] Request to review topic codelite-ide-generator

On Saturday 04 January 2014, Eran Ifrah wrote: Hi, I have added support for CodeLite IDE (topic name: codeite-ide-generator) If any of the developers can review it - it will be great P.S: This topic is related to this Mantis bug feature request:

Re: [cmake-developers] Fwd: Supporting codelite IDE

Hi Eran, On Wednesday 25 December 2013, Eran Ifrah wrote: Forwarding my email which I accidentally sent to the user's mailing list Thanks -- Forwarded message -- From: Eran Ifrah eran.if...@gmail.com Date: Wed, Dec 25, 2013 at 2:02 PM Subject: Supporting codelite IDE

Re: [cmake-developers] cmake --help-custom-modules compatibility (was: RST and documentation)

On Monday 18 November 2013, Brad King wrote: On 11/18/2013 02:56 PM, Stephen Kelly wrote: We've had a while now to get used to the new docs system. Mostly I like it, though I haven't really looked much into what rst offers. This is really the start of several threads so I will branch out

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

On Friday 08 November 2013, Daniele E. Domenichelli wrote: Hello, I updated the CMakeParseArguments_EmptyArgs topic, the new behaviour is now decided as follows: * If CMAKE_MINIMUM_REQUIRED_VERSION 2.8.13, the default behaviour is to skip empty arguments, otherwise the default

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

On Wednesday 06 November 2013, Daniele E. Domenichelli wrote: On 05/11/13 20:51, Alexander Neundorf wrote: I don't know if this is to be considered a change of behaviour though, but I'd rather consider it a bug, and I would like to see it fixed in the next bugfix release... what do you

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

On Tuesday 05 November 2013, David Cole wrote: My question is still not answered completely: When should the new variable be added? On startup is not really possible because it might be the case that your src/binary directory is not set properly. So you would agree that it makes

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

On Tuesday 05 November 2013, Jean-Christophe Fillion-Robin wrote: Would it makes sense to have cmake-gui behaving like ccmake ? After all there are both UI. It would accept the same set of options: -C initial-cache = Pre-load a script to populate the cache. -D var:type=value

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

On Tuesday 05 November 2013, Daniele E. Domenichelli wrote: Hello all, Current implementation of cmake_parse_arguments skips empty arguments. For example: cmake_parse_arguments(OPTION SINGLE MULTI ${ARGN}) with ARGN that is set using something like: args SINGLE more args #

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

On Tuesday 05 November 2013, Matthew Woehlke wrote: On 2013-11-05 14:36, Alexander Neundorf wrote: I tried the following a few times in the past and noticed everytime that it does not work: $ cd src src/ $ mkdir build src/ $ cd build src/build/ $ cmake-gui -DSOME_VARIABLE=some_value

Re: [cmake-developers] Major.Minor version install directories

On Friday 25 October 2013, Stephen Kelly wrote: Brad King wrote: ... FYI, I keep my test install tree below my build directory and wipe it out before the next install: rm -rf $whatever_you_call_the_prefix make install That doesn't work for me because my qtbase prefix is where I

Re: [cmake-developers] Review request: Qt-auto-generators

On Thursday 24 October 2013, Stephen Kelly wrote: Hi, I've pushed the Qt-auto-generators topic to stage. This topic was discussed here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7936 I have tested it with ports of KDE Frameworks and GammaRay to use the features.

Re: [cmake-developers] FindPkgConfig and CMAKE_PREFIX_PATH

On Tuesday 22 October 2013, Daniele E. Domenichelli wrote: Hello all, FindPkgConfig does not support the CMAKE_PREFIX_PATH variable. This is because pkg-config uses the PKG_CONFIG_PATH and does not know anything about CMAKE_PREFIX_PATH. As a consequence, pkg-config packages built and

Re: [cmake-developers] Fwd: CMake System Prefix Path

On Tuesday 22 October 2013, Alexander Neundorf wrote: On Tuesday 22 October 2013, Stephen Kelly wrote: Forwarding this for Ben. Would it be reasonable to have a way to not add the CMAKE_INSTALL_PREFIX to the CMAKE_SYSTEM_PREFIX_PATH? The install prefix is not cleared before the CI

  1   2   3   4   5   6   >