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_VE
2014-02-03 Brad King :
> 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
Brad King wrote:
> 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 n
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 PROJECT_
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 CPACK_PROJEC
On Wednesday 29 January 2014, Brad King wrote:
> On 1/28/2014 4:20 PM, Alexander Neundorf wrote:
> >> (1) Design new behavior in a way that requires a change to the
> >>
> >> project to activate.
> >
> > I think my current version fits (1).
>
> Yes, I meant to add "like Alex's topic currentl
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 cmake_minimum_requir
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
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7dcc
On 1/28/2014 4:20 PM, Alexander Neundorf wrote:
>> (1) Design new behavior in a way that requires a change to the
>> project to activate.
>
> I think my current version fits (1).
Yes, I meant to add "like Alex's topic currently does".
> IMO this is not the place for a policy, since the behav
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 0
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() comm
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 CMAKE_PROJECT_VER
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 wrote:
> On 01/23/2014 04:08 PM, Alexander Neundorf wrote:
> > Any more comments left ?
>
> Moving the di
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 lik
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 formattin
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 m
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
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 doc
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 formatted correctly as rst.
>
> I looked at t
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 lo
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 requi
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
> > >>
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
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 variable:
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
> > >>
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 d
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
P
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
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.
> >
On 2014-01-14 14:11, Daniel Pfeifer wrote:
2014/1/14 Matthew Woehlke :
@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 documentation for both variables i
2014/1/14 Matthew Woehlke :
> 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
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 PROJECT_VERSION_M
2014/1/14 Brad King :
> 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_M
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
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 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 t
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 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 th
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(FooConfigVersio
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 remai
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 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
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 wrote:
> On 01/06
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 A
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 b
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 proj
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.
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
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 _... equivalen
49 matches
Mail list logo
