Rolf Eike Beer wrote:
>> Of course, it is easier to get features into the CMAKE_CXX_KNOWN_FEATURES
>> list when there is only one compiler to test for on the dashboard. I'll
>> add one C++98 feature to establish the infrastructure, but I don't intend
>> to be exhaustive about C++98 features. If y
Rolf Eike Beer wrote:
>> 1) Extensions
>> I propose ignoring the granularity of XL and letting the user be more
>> granular if they wish (I think there's also granularity available with
>> GNU flags).
>
> I think just go for whatever is needed to get the requested features, if
> it enables more t
Ben Boeckel wrote:
> On Fri, Apr 04, 2014 at 15:04:50 -0400, Ben Boeckel wrote:
>> What can be merged with those branches?
>
> Looking at your branch closer, they look to be somewhat orthoganal, but
> there may be conflicts laying around.
Yes, that's my conclusion too.
I also looked at your lo
Brad King wrote:
> On 04/04/2014 11:57 AM, Stephen Kelly wrote:
>> I've pushed another commit which gets the time for the 2000 file testcase
>> from about 20s to about 4s for both Ninja and Makefiles. It fails a few
>> unit tests though and I don't have time r
Brad King wrote:
> On 04/04/2014 11:13 AM, Stephen Kelly wrote:
>> The Ninja generator was much slower than the Makefiles generator. I
>> pushed the optimize-source-file-processing topic with a commit which
>> should fix the major problem with Ninja. I'll see if there
Nils Gladitz wrote:
> Stephen is already looking into it.
> Problem seems to show with large numbers of source files e.g.:
The Ninja generator was much slower than the Makefiles generator. I pushed
the optimize-source-file-processing topic with a commit which should fix the
major problem with N
Rolf Eike Beer wrote:
> Am Freitag, 28. März 2014, 16:16:49 schrieb Stephen Kelly:
>> Hi,
>>
>> The target_compile_features topic in my clone is almost ready to merge to
>> next.
>
> Because I just had to look into the module: the stuff in
> CMakeBackwardComp
Philipp Moeller wrote:
> Hi Stephen,
>
> I'm not sure how this feature would fit in any CMake build system I
> currently maintain.
Thanks for your response.
The topic is here
https://gitorious.org/cmake/steveires-cmake/commits/target_compile_features
and the manual I wrote for it is here:
Hi,
According to packagers on IRC, documentation should be installed to
/share/doc. Currently it looks like CMake 3.0 installs to
/doc by default, if I'm reading
Source/CMakeInstallDestinations.cmake correctly.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322762
Should that be changed?
On 03/31/2014 03:50 PM, Brad King wrote:
> On 03/28/2014 05:19 PM, Nils Gladitz wrote:
>> I merged "fix_policy_diagnostics":
>>
>> http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=209980cf5a1fb472ff688127c76f24e95bff8f40
>>
>> There were few more related cases that should also be fixed
Eric Wing wrote:
> I'm thinking it will probably be two weeks before I get back to
> Android. (If things go really well, maybe late next week.)
Sounds good.
I'd like to start by syncing up on a simple hello world executable and
iterating toward the complex stuff.
Can we chat on IRC to get on
Hi,
The target_compile_features topic in my clone is almost ready to merge to
next.
Here are some remaining issues to discuss:
1) Extensions
With GNU and Clang, standard C++ features are enabled with a compile flag
something like -std=c++98 or -std=c++11. Compiler specific extensions are
en
Stephen Kelly wrote:
> There would probably need to be some properties to control it
Bill and J Decker seem to have arrived at almost this point in a subthread
discussion.
In a 'executables are linked as libraries' environment, there needs to be
some property to say &#x
Eric Wing wrote:
>> I expect so, but knowing what the needs are helps inform what those
>> changes
>>
>> might look like.
>>
>> http://public.kitware.com/Bug/view.php?id=14539
>>
>
> I'm not sure either. I recall an old thread about this
That thread is presumably the first link in the bug repor
Brad King wrote:
> On 03/21/2014 11:44 AM, Stephen Kelly wrote:
>> Should we try to add first-class support to CMake for building shared
>> libraries from CMake code like
>>
>> add_executable(...)
>>
>> somehow? There would probably need to be some prope
Eric Wing wrote:
> I have been using my fork of the Android-CMake (originally from
> OpenCV) that you want to obsolete. My fork contains a lot of fixes to
> deal with more recent NDK updates and more complicated requirements
> that I have.
> https://bitbucket.org/ewing/android-cmake
It's great to
J Decker wrote:
> I think this is impractical... the native activituy doesn't provide a hood
> to call 'main' and while you may have special code to treat main as an
> export and dynamically load it, actually stubstitute the single program
> with a loader dll and the program as a DLL, and the load
Hi,
I'd like it to be this easy to create an Android toolchain file:
set(CMAKE_SYSTEM_NAME Android)
set(ANDROID_SDK_ROOT "/home/stephen/android/android-sdk-linux/")
set(ANDROID_NDK_ROOT "/home/stephen/android/android-ndk-r9/")
set(ANDROID_NDK_PLATFORM "android-18")
set(CMAKE_FIND_ROOT_PAT
Hi,
For many years, KDE (on UNIX) has had a system of launching executables by
forking the kdeinit process and loading the application code with dlopen.
This allows avoiding the startup overhead of initializing Qt etc for each
process which is started.
Launching the konqueror application from
Brad King wrote:
>> If only the buildsystem tool knows the correct arch, does that mean that
>> CMake can not learn a built-in feature for installing object libraries,
>> because it is not possible to implement install() correctly for the files
>> for Xcode?
>
> I'd rather have a builtin feature
Brad King wrote:
> On 03/19/2014 01:41 PM, Stephen Kelly wrote:
>> However, should the macro remain when generating the buildsystem files?
>
> If the place in those files where the values get written is per-config
> then they can be replaced with the literal config names. Othe
Brad King wrote:
> On 03/19/2014 12:31 PM, Stephen Kelly wrote:
>> However, the contents of the resulting list of objects contains paths
>> which contain replacement macros '$(Configuration)' etc for the
>> buildsystem tool.
>
> At least for the configura
Hi,
In my target-sources-refactor topic, I turn TARGET_OBJECTS into a regular
generator expression. That makes it possible to use it with file(GENERATE),
and I suppose with install(FILES) too in theory.
However, the contents of the resulting list of objects contains paths which
contain replac
Brad King wrote:
> On 03/19/2014 10:26 AM, Eric Noulard wrote:
>> Current master and 3.0.0-rc2 give compile error:
>>
>> /usr/bin/ld: cannot find -lQt5::WinMain
>> collect2: error: ld returned 1 exit status
>
> Steve, do we have nightly dashboard submissions with Qt5
> on both Windows and Linux
Brad King wrote:
> However, I do not think the line
>
> set(Android 1)
>
> should appear. Projects can test CMAKE_SYSTEM_NAME if needed.
Thats fine with me. Removed.
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.
Aurélien Gâteau wrote:
>> Here is an updated patch.
Hi,
Without your patch with this code:
find_dependency(Foo "")
I get:
CMake Error at .*/Modules/CMakeFindDependencyMacro.cmake:34 (if):
if given arguments:
"STREQUAL" "EXACT"
Unknown arguments specified
Call Stack (most recen
Aurélien Gâteau wrote:
> Wrap ARGV1 and ARGV2 in quotes to avoid errors when they are empty
The user code has an error and your patch silently hides it.
How is that an improvement?
Thanks,
Steve.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
ht
Clinton Stimpson wrote:
> Thanks. I can also do a runtime check on this code with Qt5.
>
> By the way, can you confirm that you are not currently seeing compile
> errors? I don't think anyone would see these compile errors unless they
> manually add a cmake variable to the cache to enable the ut
Clinton Stimpson wrote:
>
> I personally would prefer a Qt version check
This compiles:
diff --git a/Source/QtDialog/CMakeSetup.cxx
b/Source/QtDialog/CMakeSetup.cxx
index 995929e..d1fbe9f 100644
--- a/Source/QtDialog/CMakeSetup.cxx
+++ b/Source/QtDialog/CMakeSetup.cxx
@@ -79,12 +79,14 @@ i
Hi,
I didn't follow the encoding work done by Clinton, and in my Qt 5 build with
default settings, the new codepage related definition is not set. However,
if it is set somehow, then the build would be calling methods which are not
present in Qt 5.
I've just pushed a topic fixing that, but w
Philipp Möller wrote:
> Stephen Kelly writes:
>
>> Philipp Möller wrote:
>>> It would be great, if I could export imported targets and if CMake could
>>> walk the dependency tree automatically and import those targets on an
>>> as-needed basis.
>>
&
Philipp Möller wrote:
> It would be great, if I could export imported targets and if CMake could
> walk the dependency tree automatically and import those targets on an
> as-needed basis.
Part of the problem is that the place where you import your dependent
targets from (and the locations calcula
Brad King wrote:
> On 03/04/2014 11:38 AM, Stephen Kelly wrote:
>>> If the CMAKE_SYSTEM_NAME is Android then all the Platform/Linux-*.cmake
>>> files need to have Platform/Android-*.cmake forwarding files created.
>>
>> Any reason not to prefer this?
>
>
Brad King wrote:
> On 03/04/2014 11:08 AM, Stephen Kelly wrote:
>> The resolution of
>>
>> http://public.kitware.com/Bug/view.php?id=14602
>>
>> is that all projects which wish to build libraries for Android must
>> create their own Platform/Android.c
Hello,
The resolution of
http://public.kitware.com/Bug/view.php?id=14602
is that all projects which wish to build libraries for Android must create
their own Platform/Android.cmake file.
The alternative is to ship such a file with cmake and to set
CMAKE_SYSTEM_NAME to Android, which correc
Brad King wrote:
> On 02/27/2014 03:32 AM, Stephen Kelly wrote:
>> IDE generators are problematic though.
>>
>> 'git grep GetExternalObjects' shows that the IDEs mostly don't call
>> GetExternalObjects at all.
>
> In this discussion we must disti
Hi,
Part of the work on the SOURCES genex feature is that I want to have uniform
handling of it.
So
add_library(ObjLib OBJECT a.cpp b.cpp)
add_executable(exec c.cpp d.o e.cpp $ f.cpp)
file(GENERATE OUTPUT exec_files CONTENT $)
will result in a file containing
c.cpp
d.o
e.cpp
a.o
b.o
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 refactoring
> of the CMake langua
Alex Merry wrote:
> The handling of the optional version argument in the find_dependency()
> macro is just wrong. It is only set if ${ARGV1} (rather than ARGV1)
> evaluates to true, and otherwise it remains unchanged from whatever its
> previous value was (instead of being cleared).
>
> Either o
Stephen Kelly wrote:
>
> Hi,
>
> As part of implementing the INTERFACE_SOURCES feature, a SOURCES property
> is required.
>
> Unfortunately it already exists and does not contain all sources. It omits
> TARGET_OBJECTS items. Backward compatibility must be preserved
Stephen Kelly wrote:
>> Brad informed me that Stephen Kelly is already working on two other
>> policies and CMP0050 is the latest on master, so I'll take CMP0053 for
>> the new EVIS parser behavior.
>
> Thanks, ok with me.
By the way, I have only started working o
Brad King wrote:
> On 02/19/2014 11:00 AM, Stephen Kelly wrote:
>> I've been waiting for master to re-open for features before working on
>> it.
>
> It is now open for post-3.0 development :)
Yep, great. Much better than waiting for weeks during RC phase. :)
>>
Brad King wrote:
> What is the status of this topic currently? It adds a great feature!
I've been waiting for master to re-open for features before working on it.
Here are some open issues:
1) INTERFACE_LINK_OPTIONS presents a new issue that was not present before
with the LINK_FLAGS. If I u
unt of time that it gets
tested, instead of maximizing it as happens by merging it just after 3.0.
For this parsing stuff, I'd consider that more important.
> Brad informed me that Stephen Kelly is already working on two other
> policies and CMP0050 is the latest on master, so I'll
Dan Cristiu wrote:
> What I wrote in the previous e-mails weren't attempts to influence the
> community or your design plans. Reason why I wrote such a big e-mail was
> to make my intentions to contribute known and get some feedback and
> guidance.
Did you get feedback or guidance? I'm curious to
Dan Cristiu wrote:
> Wanted to add a simple change to the VS11 generator to support non-default
> toolsets, but after taking another look through the code for the VS10
> generator and above, I decided I wasn't happy with the result. It shows
> those files have been the result of years of patches,
Marcus D. Hanwell wrote:
> On Sun, Feb 16, 2014 at 4:30 PM, Stephen Kelly
> wrote:
>> Marcus D. Hanwell wrote:
>>
>>> Hi,
>>>
>>> Is anyone working on, or have, a DeployQt5 or a generalized DeployQt4?
>>> We use it in our packaging process,
Marcus D. Hanwell wrote:
> Hi,
>
> Is anyone working on, or have, a DeployQt5 or a generalized DeployQt4?
> We use it in our packaging process, and it is one of the last things I
> need to switch to Qt 5. If not, I was going to take a look at this,
> and see what I can put together.
I've never u
Dan Cristiu wrote:
> Would appreciate if anyone could give me a hand in obtaining developer
> access.
Usually, in cases where there is still design discussion to be done, it is
preferred to put a topic on a publically hosted git repo for review instead
of pushing to the cmake repo (where it get
Rolf Eike Beer wrote:
> Am Sonntag, 16. Februar 2014, 18:43:01 schrieb Matthäus G. Chajdas:
>> Hi Eike,
>>
>> thanks for reviewing! I've just pushed a new version, which should fix
>> all the issues you mentioned. I'm also setting now Hg_FOUND using
>> FOUND_VAR (this is also recommended in the d
Rolf Eike Beer wrote:
> Matthäus G. Chajdas wrote:
>> Hi Eike,
>>
>> all right, then Hg, as it's FindHg, unless there is a naming policy I'm
>> not aware of. I was just confused a bit due to FindGit, which uses GIT_
>> as the prefix.
>>
>> How do I proceed from here? What should I do next?
>
>
Hello,
If a project() command is not written in used code, cmake will generate one.
When invoked, it sets up the toolchain.
The cmake_minimum_required() command must appear before the project()
command, so that the AppleClang compiler id may be set correctly, according
to CMP0025.
Policy CMP
On 02/12/2014 06:25 PM, Steve Wilson wrote:
> On a side note, I am running out of time for contributing these patches back
> to the project. I am spending more time responding to requests to re-order
> and change commit messages etc.. than I am changing the code (I am learning
> and will get i
Hi,
As part of implementing the INTERFACE_SOURCES feature, a SOURCES property is
required.
Unfortunately it already exists and does not contain all sources. It omits
TARGET_OBJECTS items. Backward compatibility must be preserved. I would want
to turn TARGET_OBJECTS into a 'real' generator ex
Steve Wilson wrote:
> I saved a copy of the branch in another of the repository. The commit
> numbers didn’t change and as far as I can tell they are still in the same
> order that I had them in when I initially pushed the branch.There are
> no rebases removing the downstream updates, etc...
Steve Wilson wrote:
> I just pushed the topic AddCustomCommandWithConfig to stage. This topic
> implements the CONFIG keyword for add_custom_command().
I haven't looked thoroughly, but how much does dependency
specification/handling need to change? The dependency of a command on a set
of targ
Steve Wilson wrote:
> when I do the checkout followed by the reset —hard,
> all I get is the same set of commits that I had before.
What makes you conclude they are the same?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/
Brad King wrote:
> On 02/11/2014 11:48 AM, Stephen Kelly wrote:
>> Confirmed. I added CMP0049 to control this behavior.
>
> Great.
>
> Please include a Help/release/dev/backward-compatibility.rst
> file with the relevant release note.
Will this make it into 3.0.0? Sho
Brad King wrote:
// For backwards compatibility replace varibles in source names.
- // This should eventually be removed.
+ // TODO: This should eventually be removed.
this->Makefile->ExpandVariablesInString(src);
>>>
>>> A policy should be added to remove this behavior.
>>
>> An
Brad King wrote:
> On 02/11/2014 08:46 AM, Stephen Kelly wrote:
>> We could consider making the LINK_ONLY generator expression public in
>> order to allow the user to decide the granularity here (possibly
>> encapsulated in a INTERFACE_LIBRARY).
>
> For reference, with
Brad King wrote:
> target_link_libraries(staticB INTERFACE staticA)
>
> However, that will propagate all usage requirements of A to consumers
> of B. Depending on the usage requirements specified for A and B that
> may be correct or not.
We could consider making the LINK_ONLY generator expressi
Brad King wrote:
> On 02/10/2014 03:41 AM, Stephen Kelly wrote:
>> diff --git a/Source/cmAddCustomCommandCommand.cxx
>> b/Source/cmAddCustomCommandCommand.cxx
>> index 5634849..e967e3c 100644
>> --- a/Source/cmAddCustomCommandCommand.cxx
>> +++ b/Sou
Hi,
There are some places in cmake code which are commented as being for
backward compatibility, but which seem to be covered by no policy, and some
of which have a TODO item for addressing that.
diff --git a/Source/QtDialog/QCMake.cxx b/Source/QtDialog/QCMake.cxx
index 0fe5f8c..31eb79d 100
Brad King wrote:
> Please proofread and check for your changes.
> (I'm excluding most minor/internal bug fixes.)
Done. I also have this:
diff --git a/Help/release/3.0.rst b/Help/release/3.0.rst
index 51b7de9..1f0f2e5 100644
--- a/Help/release/3.0.rst
+++ b/Help/release/3.0.rst
@@ -77,6 +77,
Brad King wrote:
> There is one more change I'd like to make as part of the change
> to the 3.0 version number. I propose that we drop the fourth
> version component and use only two components for the feature
> level.
Makes sense to me.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit
Nils Gladitz wrote:
>> Does that work if
>> the direct preprocessor flag "-Wp,-isystem,"
>
> I can't find -Wp or an equivalent in the documentation
Great, thanks for checking!
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource
Steve Wilson wrote:
> Fixed.
>
> Updated
>
> Fixed
Great, thanks for all of that. I have force-pushed your branch, which means
you need to do this before proceeding with further work.
1) Get remote changes, including my change to your branch.
You'll see output comparable to this, where your
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 use to try
>> this task?
>
> I currently only have access
Steve Wilson wrote:
>
> On Feb 6, 2014, at 3:56 PM, Stephen Kelly
> wrote:
>>
>> There are a few things I'd like to touch up a bit. How comfortable are
>> you with git? Would it cause problems for you if I force push your
>> branch, or would you know h
Ben Boeckel wrote:
> On Thu, Feb 06, 2014 at 23:44:51 +0100, Stephen Kelly wrote:
>> Ben Boeckel wrote:
>> > - cmMakefile::Get{Source,Header}Extensions returns a std::set rather
>> > than a std::vector since it was never modified and is only iterated
>> >
Steve Wilson wrote:
> I have implemented all the suggestions from the list below (modulo number
> 5 which needs more input from others). I have pushed the new branch to
> stage.
Great, thanks! I looked through it and the division among the commits looks
good to me now.
There are a few things
Ben Boeckel wrote:
> - cmMakefile::Get{Source,Header}Extensions returns a std::set rather
> than a std::vector since it was never modified and is only iterated
> over and searched in other code.
The justification is strange. Generally, the guideline with C++ stl
containers is to use std
Steve Wilson wrote:
> I’m not trying to push for this type of test of using libraries with
> target_link_options or add_link_options. (I’m already working on changes
> on the order that you suggested). My question has evolved more into the
> question of ‘what are first principles for tests?'
I d
Steve Wilson wrote:
> Now, everything you have said about not encouraging this kind of usage for
> target_link_options() and libraries, etc… is valid. However, does that
> standard apply to tests. Are tests just tests?
Admittedly, the target_compile_options tests use defines as test input. I'
Steve Wilson wrote:
> Let’s try all this again.I have a couple questions.
>
> On Feb 4, 2014, at 3:41 AM, Stephen Kelly
> wrote:
>
>> 2) The change to cmNinjaNormalTargetGenerator seems incorrect. Should
>> linkFlags should be used with AddLinkOptions?
>
&
Steve Wilson wrote:
> Ok, I’ve pushed the new changes.
Are you sure? Looking at the top commit, I don't see any change to the
ExportImport test.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Ple
Micha Hergarden wrote:
> I have checked out and build the most recent versions to figure out when
> this phenomena is introduced, and have narrowed it down to the following
> commit :
> 4b989d5f158e5135bf543438af00b03db0102ade
Hi,
Thanks for investigating and reporting!
> My questions:
> - I any
Alex Merry wrote:
>> I don't think there is a need to change the cmake-qt manual. I've pushed
>> the rest to next for testing.
>
> OK. The wording did end up getting quite complicated in the cmake-qt
> manual. It might be worth having something like "see the documentation
> for that property for
Alex Merry wrote:
> If you have a header file like foo.h and the corresponding source file
> is, say, foo_win.cpp, automoc will never look at foo.h.
... unless you include moc_foo.cpp in foo_win.cpp, right?
> The attached patch makes the documentation clear on this point.
Please create patches
Stephen Kelly wrote:
> 7) I've added two commits to your branch. Please squash them into the
> appropriate commits in your topic.
>
Oh, forgot this one:
8) I get some unit test failures:
The following tests FAILED:
85 - LinkFlags-dll_config (Failed)
87 - LinkFl
hem into the
appropriate commits in your topic.
Thanks,
Steve.
> Thanks,
>
> SteveW
>
> On Feb 2, 2014, at 2:44 AM, Stephen Kelly
> wrote:
>
>> Steve Wilson wrote:
>>
>>> I have just pushed the LinkOptionsCommand topic branch
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
Brad King wrote:
>
>> 2)
>> Signatures are introduced in prose after their appearance.
>
> I've never been happy with this style. The literal block with
> a signature does not stand out as the beginning of a "section"
> and looks more like the end. It works cleanly only when there
> is just o
Matthew Woehlke wrote:
> I guess you mean that in a '..code-block:: cmake' block, kate should
> apply the CMake HL rules? (What about other languages; I guess the same
> argument would apply to e.g. C++, Python, etc?)
Kate already does that, since my recent patches to the cmake rst
highlighting r
Brad King wrote:
> On 02/02/2014 04:01 PM, Stephen Kelly wrote:
>> source_group.rst contains this:
>>
>> .. code-block:: cmake
>>
>>source_group( [FILES ...] [REGULAR_EXPRESSION ])
>>
>>
>> That block of code is not cmake code,
Brad King wrote:
> On 02/02/2014 04:12 PM, Stephen Kelly wrote:
>> I was investigating the fact that target_compile_options accepts a BEFORE
>> keyword. The keyword is ignored, by the command implementation, but could
>> be used by cmTarget. Should it be? Is the bug in t
Hi,
It's generally preferable to write an email and attach the patch.
Alex Merry wrote:
> -# informative diagnostic message if the dependency could not be found.
> +# informative diagnostic message if the dependency could not be found,
> and +# marks the package as a TRANSITIVE_DEPENDENCY for
>
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_PRO
Hi,
I pushed update-buildsystem-docs to my clone. Generally, I want to make sure
that the links one hop away from the primary new manuals are properly marked
up as rst for the release.
I need a style guide for that, so I wrote one as a starting point for
discussion.
Style
-
1)
Comman
Hi,
I was investigating the fact that target_compile_options accepts a BEFORE
keyword. The keyword is ignored, by the command implementation, but could be
used by cmTarget. Should it be? Is the bug in target_compile_options
accepting the option, or in ignoring it?
The same question applies
Hi,
source_group.rst contains this:
.. code-block:: cmake
source_group( [FILES ...] [REGULAR_EXPRESSION ])
That block of code is not cmake code, but it is marked as such in the rst.
That seems inappropriate. I suggest removing the 'cmake' language specifier.
This repeats in many places
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
Steve Wilson wrote:
> I have just pushed the LinkOptionsCommand topic branch to stage. This
> topic branch contains commits that implement support for:
>
> add_link_options()
>
> target_link_options()
>
> and the LINK_OPTIONS variable.
>
> Please take a look as interested and send me feedbac
Nils Gladitz wrote:
> On 01/31/2014 02:27 PM, Stephen Kelly wrote:
>> help? If so, can you see about adding a unit test and merging to next?
>
> I merged "fix-visibility-inlines-hidden" to "next" with a new test
> "VisibilityInlinesHidden".
&g
Nils Gladitz wrote:
> I found CMAKE_VISIBILITY_INLINES_HIDDEN and wanted to replace my custom
> gcc flag with it.
>
> For C it causes the warning: "command line option
> ‘-fvisibility-inlines-hidden’ is valid for C++/ObjC++ but not for C".
>
> Independent of the actual language the code currentl
Steve Wilson wrote:
> While I didn’t see a
> specific policy for COMPILE_FLAGS moving to COMPILE_OPTIONS, the sources
> seem to indicate that COMPILE_FLAGS_ (and indeed the use of
> COMPILE_FLAGS) will be deprecated in favor of COMPILE_OPTIONS and the
> newer methods of modifying COMPILE_OPTIONS su
Brad King wrote:
> On 01/28/2014 12:35 PM, Stephen Kelly wrote:
>> Brad King wrote:
>>
>>>> Alternatively, consider something like the no-duplicate-install-doc-src
>>>> topic in my clone instead.
>>>
>>> We can't reference the source
Brad King wrote:
>> Alternatively, consider something like the no-duplicate-install-doc-src
>> topic in my clone instead.
>
> We can't reference the source tree for redistributable docs.
Oh, I didn't intend for that. What about using a relative path?
Thanks,
Steve.
--
Powered by www.kitwar
Brad King wrote:
>> /home/stephen/dev/prefix/qtbase/kde/doc/cmake-2.8.12/html/_sources/*
>
> Those are for the "Show Source" links on each page.
I don't think that's valuable. I'd just remove the link.
Alternatively, consider something like the no-duplicate-install-doc-src
topic in my clone i
Matthew Woehlke wrote:
> On 2014-01-27 16:58, Stephen Kelly wrote:
>> Though I still don't like the behavior in the topic with project()
>> commands without a specified VERSION and the
>> CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND variable etc. I don't see
>
301 - 400 of 1446 matches
Mail list logo
