Hi,
again from the KDE sprint...
1) We have a macro
macro_optional_find_package().
The purpose is to be able to build without a specific package even if that
package is installed and would actually be found by the find_package() call.
Basically this is a wrapper around find_package(), but addit
2011/6/4 Alexander Neundorf :
> Hi,
>
> again from the KDE sprint...
>
> 1) We have a macro
> macro_optional_find_package().
> The purpose is to be able to build without a specific package even if that
> package is installed and would actually be found by the find_package() call.
>
> Basically this
On Sunday, June 05, 2011 11:50:50 PM Eric Noulard wrote:
> 2011/6/4 Alexander Neundorf :
> > Hi,
> >
> > again from the KDE sprint...
> >
> > 1) We have a macro
> > macro_optional_find_package().
> > The purpose is to be able to build without a specific package even if
> > that package is install
2011/6/6 Alexander Neundorf :
> On Sunday, June 05, 2011 11:50:50 PM Eric Noulard wrote:
>> 2011/6/4 Alexander Neundorf :
>> > Hi,
>> >
>> > again from the KDE sprint...
>> >
>> > 1) We have a macro
>> > macro_optional_find_package().
>> > The purpose is to be able to build without a specific packa
On Sun, Jun 5, 2011 at 4:44 PM, Alexander Neundorf wrote:
> On Sunday, June 05, 2011 11:50:50 PM Eric Noulard wrote:
> > 2011/6/4 Alexander Neundorf :
> > > Hi,
> > >
> > > again from the KDE sprint...
> > >
> > > 1) We have a macro
> > > macro_optional_find_package().
> > > The purpose is to be
On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
> What do you think about adding this as a built-in feature to find_package(),
> i.e. add a argument OPTIONAL to find_package(), then probably also a
> "COMMENT".
The interface to find_package is already extensive. This feature would
have to com
On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
> On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
> > What do you think about adding this as a built-in feature to
> > find_package(), i.e. add a argument OPTIONAL to find_package(), then
> > probably also a "COMMENT".
>
> The interface to fi
2011/6/7 Alexander Neundorf :
> On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
>> On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
[...]
>> >
>> > What do you think about adding the keyword OPTIONAL to add_subdirectory ?
>> >
>> > Both have been proven useful, the one for find_package() es
2011/6/7 Eric Noulard :
> 2011/6/7 Alexander Neundorf :
>> On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
>>> On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
> [...]
>
>>> >
>>> > What do you think about adding the keyword OPTIONAL to add_subdirectory ?
>>> >
>>> > Both have been proven us
On Tuesday, June 07, 2011 02:34:06 PM Eric Noulard wrote:
> 2011/6/7 Alexander Neundorf :
> > On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
> >> On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
> [...]
>
> >> > What do you think about adding the keyword OPTIONAL to
> >> > add_subdirectory
On Jun 8, 2011, at 12:08 PM, Alexander Neundorf wrote:
> On Tuesday, June 07, 2011 02:34:06 PM Eric Noulard wrote:
>> 2011/6/7 Alexander Neundorf :
>>> On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
>> [...]
>>
> What do you think
2011/6/8 Alexander Neundorf :
> On Tuesday, June 07, 2011 02:34:06 PM Eric Noulard wrote:
>> 2011/6/7 Alexander Neundorf :
>> > On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
>> >> On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
>> [...]
>>
>> >> > What do you think about adding the keywor
On Wednesday, June 08, 2011 08:45:56 PM Eric Noulard wrote:
> 2011/6/8 Alexander Neundorf :
> > On Tuesday, June 07, 2011 02:34:06 PM Eric Noulard wrote:
> >> 2011/6/7 Alexander Neundorf :
> >> > On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
> >> >> On 06/04/2011 06:30 AM, Alexander Neundor
On 6/8/2011 2:08 PM, Alexander Neundorf wrote:
> This would make the options available for cmake-based projects more
> consistent.
> This issue comes up regularly from new users.
The option() command adds options. The add_subdirectory command
adds subdirectories. The find_package command finds
On Wed, Jun 8, 2011 at 8:08 PM, Alexander Neundorf wrote:
> On Tuesday, June 07, 2011 02:34:06 PM Eric Noulard wrote:
>> 2011/6/7 Alexander Neundorf :
>> > On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
>> >> On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
>> [...]
>>
>> >> > What do you
Nicolas Desprès wrote:
> I have to confess that I never called find_package() without REQUIRED,
> and I can't think about any use case right now.
The most simple one is probably the system-or-bundled one: check if the system
has a good version of some package, use the one bundled with the sources
On Thursday 09 June 2011, Nicolas Desprès wrote:
> On Wed, Jun 8, 2011 at 8:08 PM, Alexander Neundorf wrote:
...
> > I can't think of any reason why somebody would want to use
> > find_package(...without REQUIRED) instead of optional_find_package().
> >
> > Can somebody else see a reason ?
>
> I
On Wednesday 08 June 2011, Brad King wrote:
> On 6/8/2011 2:08 PM, Alexander Neundorf wrote:
> > This would make the options available for cmake-based projects more
> > consistent.
> > This issue comes up regularly from new users.
>
> The option() command adds options. The add_subdirectory comman
On 6/9/2011 2:58 AM, Alexander Neundorf wrote:
> This wish comes mainly from packagers, not from the developers themselves.
> I am sure packagers would be happy if they had one consistent way to disable
> every package any cmake checks for with a standardized option.
This is a nice goal, but I do
On Thursday 09 June 2011, Brad King wrote:
> On 6/9/2011 2:58 AM, Alexander Neundorf wrote:
> > This wish comes mainly from packagers, not from the developers
> > themselves. I am sure packagers would be happy if they had one
> > consistent way to disable every package any cmake checks for with a
>
On 6/9/2011 8:50 AM, Alexander Neundorf wrote:
> Calling FindQt4 in some directory with components A and B, and in some other
> directory with component C, and the second one doesn't do anything because
> the
> first one has already set something to "I am done" already so the second one
> doesn
On Thu, Jun 9, 2011 at 9:19 AM, Brad King wrote:
> On 6/9/2011 8:50 AM, Alexander Neundorf wrote:
>>> What if the FindFoo.cmake script calls find_package(Bar) and does
>>> not require it but the project also does find_package(Bar) and does? I'm
>>> sure there are more cases I haven't listed here.
On Thursday 09 June 2011, Brad King wrote:
> On 6/9/2011 8:50 AM, Alexander Neundorf wrote:
...
> > I think this can be handled.
> > find_package() should error out in this case, because Bar was required
> > but it was disabled.
> > Maybe this option to disable a find_package() could even be provid
On 06/16/2011 04:15 PM, Alexander Neundorf wrote:
> I'll push a branch to the stage once 2.8.5 is released. Or can I do that
> earlier ?
You can push it any time but skip merging it.
Don't expect it to be in 2.8.5 though ;)
Thanks,
-Brad
___
cmake-dev
On Thursday 16 June 2011, Brad King wrote:
> On 06/16/2011 04:15 PM, Alexander Neundorf wrote:
> > I'll push a branch to the stage once 2.8.5 is released. Or can I do that
> > earlier ?
>
> You can push it any time but skip merging it.
There should be a branch DisableSwitchForFindPackage now in s
On 06/17/2011 12:55 PM, Alexander Neundorf wrote:
> On Thursday 16 June 2011, Brad King wrote:
>> On 06/16/2011 04:15 PM, Alexander Neundorf wrote:
>>> I'll push a branch to the stage once 2.8.5 is released. Or can I do that
>>> earlier ?
>>
>> You can push it any time but skip merging it.
>
> The
On Monday 20 June 2011, Brad King wrote:
> On 06/17/2011 12:55 PM, Alexander Neundorf wrote:
> > On Thursday 16 June 2011, Brad King wrote:
> >> On 06/16/2011 04:15 PM, Alexander Neundorf wrote:
> >>> I'll push a branch to the stage once 2.8.5 is released. Or can I do
> >>> that earlier ?
> >>
> >
On Monday 20 June 2011, Alexander Neundorf wrote:
...
> What is the recommended way how to do this with git ?
with "how to do this" I mean "how to make the suggested fixes"
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.
On 06/20/2011 12:40 PM, Alexander Neundorf wrote:
> On Monday 20 June 2011, Brad King wrote:
>> - In the documentation patch please move mention of this variable down
>> to the bottom. It is not important information for general authors
>> learning the command. Certainly this information does
On 06/20/2011 07:46 PM, Brad King wrote:
> On 06/20/2011 12:40 PM, Alexander Neundorf wrote:
>
>> What is the recommended way how to do this with git ?
>>
>> Simply add one more commit which does that or do I have to do something with
>> rebase --interactive ?
>> How does that play together with
On Monday 20 June 2011, Brad King wrote:
...
> As you guessed, interactive rebase is the correct approach. Since
> you have not merged the topic you are free to overwrite it on the
> topic stage. The old version of the history will be replaced with
> the new version. It might feel funny the firs
On 06/20/2011 05:14 PM, Alexander Neundorf wrote:
> Hmm, I think I managed the rebasing, but now git complains when I try to push:
>
> hammer:~/src/CMake/CMake-git$ git push stage HEAD
> To g...@public.kitware.com:stage/cmake.git
> ! [rejected]HEAD -> DisableSwitchForFindPackage (non-fast
On Monday 20 June 2011, Alexander Neundorf wrote:
> On Monday 20 June 2011, Brad King wrote:
> ...
>
> > As you guessed, interactive rebase is the correct approach. Since
> > you have not merged the topic you are free to overwrite it on the
> > topic stage. The old version of the history will be
On Monday 20 June 2011, Brad King wrote:
> On 06/20/2011 12:40 PM, Alexander Neundorf wrote:
> > On Monday 20 June 2011, Brad King wrote:
> >> - In the documentation patch please move mention of this variable down
> >>
> >> to the bottom. It is not important information for general authors
> >>
On 06/20/2011 06:23 PM, Alexander Neundorf wrote:
> I moved part of the documentation now to the variable section.
>
> Better ?
Nice, thanks.
> While looking at it, I'm not sure anymore the name
> "DISABLE_FIND_PACKAGE_" is good.
>
> Should it maybe have the "CMAKE_" prefix ?
Yes, good idea.
On Tuesday 21 June 2011, Brad King wrote:
> On 06/20/2011 06:23 PM, Alexander Neundorf wrote:
> > I moved part of the documentation now to the variable section.
> >
> > Better ?
>
> Nice, thanks.
>
> > While looking at it, I'm not sure anymore the name
> > "DISABLE_FIND_PACKAGE_" is good.
> >
>
On 06/21/2011 03:25 PM, Alexander Neundorf wrote:
> Ok, I pushed the branch again.
The new name looks better. Perhaps I missed this last time, but the
documentation of the variable within the command is back up in the
simple section. Please put it at the very bottom of the entire
documentation,
On Wednesday 22 June 2011, Brad King wrote:
> On 06/21/2011 03:25 PM, Alexander Neundorf wrote:
> > Ok, I pushed the branch again.
>
> The new name looks better. Perhaps I missed this last time, but the
> documentation of the variable within the command is back up in the
> simple section.
Yes,
On 06/23/2011 05:12 AM, Alexander Neundorf wrote:
>> Please put it at the very bottom of the entire
>> documentation, just above the note about NO_POLICY_SCOPE.
>
> Done.
Thanks. The topic looks good. Please merge it to 'next' when
you're ready.
-Brad
__
On Thursday 23 June 2011, Brad King wrote:
> On 06/23/2011 05:12 AM, Alexander Neundorf wrote:
> >> Please put it at the very bottom of the entire
> >> documentation, just above the note about NO_POLICY_SCOPE.
> >
> > Done.
>
> Thanks. The topic looks good. Please merge it to 'next' when
> you'
On 06/23/2011 09:53 AM, Alexander Neundorf wrote:
> On Thursday 23 June 2011, Brad King wrote:
>> On 06/23/2011 05:12 AM, Alexander Neundorf wrote:
Please put it at the very bottom of the entire
documentation, just above the note about NO_POLICY_SCOPE.
>>>
>>> Done.
>>
>> Thanks. The top
On 06/23/2011 04:11 PM, Brad King wrote:
> On 06/23/2011 09:53 AM, Alexander Neundorf wrote:
>> On Thursday 23 June 2011, Brad King wrote:
>>> On 06/23/2011 05:12 AM, Alexander Neundorf wrote:
> Please put it at the very bottom of the entire
> documentation, just above the note about NO_POL
On 06/23/2011 10:36 AM, Michael Wild wrote:
> On 06/23/2011 04:11 PM, Brad King wrote:
>> We manually select topics from 'next' and merge them to 'master'.
>> Only topics in master will be released.
>
> So, how does that work? Do you look for the merges in 'next' that you
> like, and then re-merge
On 06/23/2011 06:02 PM, Brad King wrote:
> On 06/23/2011 10:36 AM, Michael Wild wrote:
>> On 06/23/2011 04:11 PM, Brad King wrote:
>>> We manually select topics from 'next' and merge them to 'master'.
>>> Only topics in master will be released.
>>
>> So, how does that work? Do you look for the merg
44 matches
Mail list logo
