2014-02-03 Brad King brad.k...@kitware.com:
On 02/02/2014 03:49 PM, Stephen Kelly wrote:
Should this topic set the CPACK_PROJECT_VERSION variable? Or should cpack
first try to read PROJECT_VERSION, and only use CPACK_PROJECT_VERSION as a
fallback?
I think it should read CPACK_PROJECT_VERSION
Eric Noulard wrote:
that said CPACK_PROJECT_VERSION does not currently exist.
Oops, my mistake.
So do you want:
1) to create new CPACK_PROJECT_VERSION vars?
If yes, what is the purpose?
2) feed current CPACK_PACKAGE_VERSION* vars with the one found in
CMAKE_PROJECT_VERSION* ?
On 02/02/2014 03:49 PM, Stephen Kelly wrote:
Should this topic set the CPACK_PROJECT_VERSION variable? Or should cpack
first try to read PROJECT_VERSION, and only use CPACK_PROJECT_VERSION as a
fallback?
I think it should read CPACK_PROJECT_VERSION and if that is not set
then try
Brad King wrote:
I reverted the 'AddVersionToProjectCommand' topic from 'next'
and replaced it with a 'project-version-variables' topic that
adds a policy:
Should this topic set the CPACK_PROJECT_VERSION variable? Or should cpack
first try to read PROJECT_VERSION, and only use
On 2014-01-29 09:58, Brad King wrote:
I reverted the 'AddVersionToProjectCommand' topic from 'next'
and replaced it with a 'project-version-variables' topic that
adds a policy:
Help: Format project command and variable documentation
On 01/29/2014 10:33 AM, Matthew Woehlke wrote:
Can one use project(VERSION) and later set the policy to OLD to get the
old, don't-unset-the-variables behavior from that point onwards?
Yes. A subproject that has not been updated to understand the
policy would normally run
On 01/23/2014 04:08 PM, Alexander Neundorf wrote:
Any more comments left ?
Moving the discussion from
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9156/focus=9158
back to the thread where it belongs:
On 01/27/2014 04:58 PM, Stephen Kelly wrote:
Though I still don't like
I would vote for (2), that way people using the latest and greatest of
CMake won't have to enable any variable and it will work out of the box.
Jc
On Tue, Jan 28, 2014 at 9:10 AM, Brad King brad.k...@kitware.com wrote:
On 01/23/2014 04:08 PM, Alexander Neundorf wrote:
Any more comments left
On 01/28/2014 11:16 AM, Jean-Christophe Fillion-Robin wrote:
I would vote for (2), that way people using the latest and greatest
of CMake won't have to enable any variable and it will work out of the box.
No one has to set a magic variable in Alex's current design either.
The
On 2014-01-28 11:16, Jean-Christophe Fillion-Robin wrote:
On Tue, Jan 28, 2014 at 9:10 AM, Brad King wrote:
So our options are
(1) Design new behavior in a way that requires a change to the
project to activate.
(2) Add a policy. The policy should only trigger when the
project()
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
On 01/24/2014 08:13 PM, Stephen Kelly wrote:
Simply look at the existing docs in Help/manual in particular, and do what
they do. I hesitate to be specific about what is missing in your topic in
case that limits what you look for, but 'Link to variables' etc.
As an example of the formatting
Alexander Neundorf wrote:
Is it actually recommended to use some formatting, like bold or italic or
something else ?
The question is both too-vague and too specific.
Simply look at the existing docs in Help/manual in particular, and do what
they do. I hesitate to be specific about what is
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,
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 is not
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.
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,
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
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.e. it could happen when the version number of a sub-project changes,
Generally for cmake, things that require
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
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 A
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, this could be worked around by
unsetting the guard
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 for PROJECT_VERSION_MAJOR, but this is maybe less
2014/1/14 Brad King brad.k...@kitware.com:
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 for
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 would now unset Foo_VERSION_MAJOR.
The same for
2014/1/14 Matthew Woehlke mw_tr...@users.sourceforge.net:
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
On 2014-01-14 14:11, Daniel Pfeifer wrote:
2014/1/14 Matthew Woehlke mw_tr...@users.sourceforge.net:
@Daniel, there is a CMAKE_PROJECT_NAME?
http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:CMAKE_PROJECT_NAME
http://cmake.org/cmake/help/v2.8.12/cmake.html#variable:PROJECT_NAME
The
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 for
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
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
to start using project(...VERSION...). Now if B was using
On 10/01/14 21:19, Alexander Neundorf wrote:
Should the full version 1.2.3 be put into PROJECT_VERSION or
PROJECT_VERSION_STRING ?
Both forms are used in different places in cmake.
I usually consider PROJECT_VERSION = Major.Minor.Patch and
PROJECT_VERSION_STRING as a customizable string that
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)
...
On 01/06/2014 04:41 PM, Alexander Neundorf wrote:
I modified write_basic_package_version_file() accordingly, so that you can
now
simply do
project(Foo VERSION 1.2.3)
...
write_basic_package_version_file(FooConfigVersion.cmake
COMPATIBILITY
Would it make sense to have project(Foo VERSION 1.2.3) set the variables:
${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)
That way, the variable would remain even if project is called with VERSION
in sub directory.
Jc
On Fri, Jan 10, 2014 at 9:49 AM, Brad King
On 2014-01-10 11:01, Jean-Christophe Fillion-Robin wrote:
Would it make sense to have project(Foo VERSION 1.2.3) set the variables:
${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)
That way, the variable would remain even if project is called with VERSION
in sub directory.
How is
Great.
Having both:
PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)
${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)
is the way to to go.
On Fri, Jan 10, 2014 at 11:41 AM, Matthew Woehlke
mw_tr...@users.sourceforge.net wrote:
On 2014-01-10 11:01, Jean-Christophe Fillion-Robin wrote:
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
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
On 2014-01-10 15:15, Alexander Neundorf wrote:
On Friday 10 January 2014, Matthew Woehlke wrote:
Related: Do these affect the version properties of libraries? (Because
OTOH if it does, I can imagine wanting to say VERSION once at the root
and have it inherit downwards unless overridden. Maybe
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)
...
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
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
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)
Cool, I like this. Shouldn't there be spaces on both sides
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)
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 AddVersionToProjectCommand.
This extends the project command to
45 matches
Mail list logo
