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, you
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're ready.
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_POLICY_SCOPE.
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 them
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 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_Name is good.
Should it
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.
There should be a
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
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 not
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 the branch
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 first
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
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 stage.
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 provided for
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
___
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 neund...@kde.org 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
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 Thu, Jun 9, 2011 at 9:19 AM, Brad King brad.k...@kitware.com 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
On Tuesday, June 07, 2011 02:34:06 PM Eric Noulard wrote:
2011/6/7 Alexander Neundorf neund...@kde.org:
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
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 neund...@kde.org:
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
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 neund...@kde.org wrote:
On Tuesday, June 07, 2011 02:34:06 PM Eric Noulard wrote:
2011/6/7 Alexander Neundorf neund...@kde.org:
On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
[...]
2011/6/7 Alexander Neundorf neund...@kde.org:
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()
2011/6/7 Eric Noulard eric.noul...@gmail.com:
2011/6/7 Alexander Neundorf neund...@kde.org:
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
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 come
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 find_package
2011/6/4 Alexander Neundorf neund...@kde.org:
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.
On Sunday, June 05, 2011 11:50:50 PM Eric Noulard wrote:
2011/6/4 Alexander Neundorf neund...@kde.org:
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
2011/6/6 Alexander Neundorf neund...@kde.org:
On Sunday, June 05, 2011 11:50:50 PM Eric Noulard wrote:
2011/6/4 Alexander Neundorf neund...@kde.org:
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
On Sun, Jun 5, 2011 at 4:44 PM, Alexander Neundorf neund...@kde.org wrote:
On Sunday, June 05, 2011 11:50:50 PM Eric Noulard wrote:
2011/6/4 Alexander Neundorf neund...@kde.org:
Hi,
again from the KDE sprint...
1) We have a macro
macro_optional_find_package().
The purpose
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
34 matches
Mail list logo
