[cmake-developers] [CMake 0012255]: CMAKE_SIZEOF_VOID_P not set
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=12255
==
Reported By:Vivien Delmon
Assigned To:
==
Project:CMake
Issue ID: 12255
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2011-06-08 04:23 EDT
Last Modified: 2011-06-08 04:23 EDT
==
Summary:CMAKE_SIZEOF_VOID_P not set
Description:
This simple CMakeLists.txt does not print the CMAKE_SIZEOF_VOID_P variable.
project (test)
cmake_minimum_required (VERSION 2.6)
message("CMAKE_SIZEOF_VOID_P = ${CMAKE_SIZEOF_VOID_P}")
==
Issue History
Date ModifiedUsername FieldChange
==
2011-06-08 04:23 Vivien Delmon New Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Integration of manpage installation
2011/6/7 Michael Wild : > On 06/07/2011 07:40 PM, Werner Mahr wrote: >> Michael Wild wrote: [...] >> I don't think that writing >> stuff like this in many different projects is a good idea, that's why I >> proposed to include it native in cmake. >> >> ADD_EXECUTABLE(, ) >> SET_TARGET_PROPERTIES ( PROPERTIES MAN_SOURCES "docs/man/") >> >> is much easier to write. Expected behaviour is to install above >> mentioned sheme docs/man/* to the right places. >> >> From my point as a dev participating in more than one prjoect it would >> be a pita to try to understand how they implemented their manpage- >> installation, plus it would slim down many projects lot. >> > > IMHO, sounds an awful lot like DWIM to me, but others might disagree. I > don't think that CMake could satisfy everybody by using such a scheme. > Just my 2c... Agreed. When the tool you use is too smart you end-up scratching your head forever when the smart behavior breaks. Be sure that the smart feature you handle WILL be broken by some unexpected usage and one will have to handle the bug reports it generates. I think, CMake should have solid not-too-basic cross-platform features set then if you want something smart, then write a CMake module which may eventually go upstream. In the end if the smart behavior breaks then you know where to look at. Moreover MAN pages are a Unix things and CMake has to work on Windows too. I would rather avoid platform-specific things in CMake builtin, currently there is not so much such things (besides WIN32 and MAC_OSBUNDLE) and I find it should stay that way if possible. My 2.5 c :-] -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012256]: cpack should sanitize component names
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=12256
==
Reported By:Daniel Franke
Assigned To:
==
Project:CMake
Issue ID: 12256
Category: CPack
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2011-06-08 10:49 EDT
Last Modified: 2011-06-08 10:49 EDT
==
Summary:cpack should sanitize component names
Description:
Working on an Windows NSIS installer with components. Consider:
add_executable(targetname ...)
install (targetname COMPONENT "foo/bar")
cpackk_add_component("foo/bar" DISPLAY_NAME "blabla" ...)
this results in CPackConfig.cmake:
# Configuration for component "foo/bar"
SET(CPACK_COMPONENT_FOO/BAR_DISPLAY_NAME "blabla")
The component "foo/bar" does not show up in the installer afterwards. The
component names should probably be sanitised with regard to '/' and possibly
other characters not allowed in variable names?!
Observed with cmake 2.8.1 on Windows, NSIS version 2.46.
==
Issue History
Date ModifiedUsername FieldChange
==
2011-06-08 10:49 Daniel Franke New Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory
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 ? > >> > > >> > Both have been proven useful, the one for find_package() especially > >> > for packagers. > >> > >> Ditto previous response. These commands are primitives. We should not > >> extend them with features unrelated to their basic purpose. > > > > While this is correct, it also keeps cmake a bit low-level. > > For this reason, we created such macros in KDE. > > Now our developers write stuff outside KDE, so either they can't use it, > > or they create copies of these files. > > This may be ok, but having 50 or 100 versions of these files and macros > > around in the net, some probably differing slightly, is also not a nice > > situation. > > Then it is possible to create a new CMake module, > > say > > UseEnhancedConfigure.cmake > > which could be included in CMake as a contributed module maintained by KDE > dev. This new module would define something like: > > optional_find_package(). > optional_add_subdirectory() > > this would make the feature available upstream, thus available outside KDE > and does not add extra feature to builtin configure. 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 ? > > These two OPTION features in this email are IMO features which are useful > > in many projects and which would make using cmake-based projects easier > > for users (people compiling the software), since they could expect that > > if packages can be disabled, that this will be done via an option with a > > name which always follows the same scheme. > > I totally agree with that but I think it does not implies this has to be > done by builtin find_package/add_subdirectory ? Well, it doesn't have to. But if packagers requested this for something in KDE, they will also want this for non-KDE projects. And I see no reason why this shouldn't be the default for _every_ non-REQUIRED package. This would make the options available for cmake-based projects more consistent. This issue comes up regularly from new users. So, I don't see a reason why such an option should not be the default behaviour and why I should rely on an external extension. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Getting some stuff from KDE into cmake
On Saturday, June 04, 2011 10:09:57 AM Alexander Neundorf wrote: > Hi, > > I'm currently at the KDE Platform Sprint, where we (a bunch of KDE > developers) are discussing how to move on with the KDE platform. > This includes some things regarding cmake. > When we introduced cmake in KDE, there were not that many other free > projects using cmake, so our cmake extensions was added to kdelibs, so all > users of kdelibs have it available. > The situation has changed in the last 5 years, and now more and more > projects "before" kdelibs are using cmake, and they'd like to have some of > those things available too. > > So there is a string wish to get some of our cmake stuff upstreamed, some > parts up into cmake, and some parts only half way up. > > So what I'm doing now is I'll write for each wish we have an email here, > and it would be nice if you could check whether whether each one sounds > reasonable or not. > > I am here at the sprint until Tuesday, so until then I'll have basically 4 > full days to work on the stuff. After that it'll be again only one or two > hours in the evenings... After the responses to my other mails I'd like to describe the situation we are in a bit more. We are using CMake in KDE now since more than 5 years (it was beginning 2006). Since then hundreds of developers have started to use CMake in KDE, and I have heard from many of our developers who are also software developer in their real life, that they also introduced CMake at their workplace. I didn't write the emails with the proposals because I'm bored and have nothing better to do, but based on the experience and feedback from (hundreds of) developers and also distro packagers during the last 5 years. This is not every tiny module or every idea somebody came up with, but the things which are used very widely or wishes which come up permanently from many people. So I'd appreciate if they could be considered seriously. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and 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 about adding the keyword OPTIONAL to
> add_subdirectory ?
>
> Both have been proven useful, the one for find_package() especially
> for packagers.
Ditto previous response. These commands are primitives. We should not
extend them with features unrelated to their basic purpose.
>>>
>>> While this is correct, it also keeps cmake a bit low-level.
>>> For this reason, we created such macros in KDE.
>>> Now our developers write stuff outside KDE, so either they can't use it,
>>> or they create copies of these files.
>>> This may be ok, but having 50 or 100 versions of these files and macros
>>> around in the net, some probably differing slightly, is also not a nice
>>> situation.
>>
>> Then it is possible to create a new CMake module,
>>
>> say
>>
>> UseEnhancedConfigure.cmake
>>
>> which could be included in CMake as a contributed module maintained by KDE
>> dev. This new module would define something like:
>>
>> optional_find_package().
>> optional_add_subdirectory()
>>
>> this would make the feature available upstream, thus available outside KDE
>> and does not add extra feature to builtin configure.
>
> 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 ?
>
>
>>> These two OPTION features in this email are IMO features which are useful
>>> in many projects and which would make using cmake-based projects easier
>>> for users (people compiling the software), since they could expect that
>>> if packages can be disabled, that this will be done via an option with a
>>> name which always follows the same scheme.
>>
>> I totally agree with that but I think it does not implies this has to be
>> done by builtin find_package/add_subdirectory ?
>
> Well, it doesn't have to.
> But if packagers requested this for something in KDE, they will also want
> this
> for non-KDE projects.
> And I see no reason why this shouldn't be the default for _every_
> non-REQUIRED
> package.
> This would make the options available for cmake-based projects more
> consistent.
> This issue comes up regularly from new users.
>
> So, I don't see a reason why such an option should not be the default
> behaviour and why I should rely on an external extension.
Just something that came to mind... what if one wanted one cmake option that
corresponds with multiple find_package()'s.
But then wouldn't the following work for that case?
option(MYOPTION... )
set(FOO_OPTION ${MYOPTION} CACHE INTERNAL "")
set(BAR_OPTION ${MYOPTION} CACHE INTERNAL "")
find_package(FOO)
find_package(BAR)
Clint
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory
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 keyword OPTIONAL to >> >> > add_subdirectory ? >> >> > >> >> > Both have been proven useful, the one for find_package() especially >> >> > for packagers. >> >> >> >> Ditto previous response. These commands are primitives. We should not >> >> extend them with features unrelated to their basic purpose. >> > >> > While this is correct, it also keeps cmake a bit low-level. >> > For this reason, we created such macros in KDE. >> > Now our developers write stuff outside KDE, so either they can't use it, >> > or they create copies of these files. >> > This may be ok, but having 50 or 100 versions of these files and macros >> > around in the net, some probably differing slightly, is also not a nice >> > situation. >> >> Then it is possible to create a new CMake module, >> >> say >> >> UseEnhancedConfigure.cmake >> >> which could be included in CMake as a contributed module maintained by KDE >> dev. This new module would define something like: >> >> optional_find_package(). >> optional_add_subdirectory() >> >> this would make the feature available upstream, thus available outside KDE >> and does not add extra feature to builtin configure. > > 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 ? Our e-mails crossed each-other. Yes you are right default behavior of making find_package(...without REQUIRED) This is a different story for add_subdirectory. >> > These two OPTION features in this email are IMO features which are useful >> > in many projects and which would make using cmake-based projects easier >> > for users (people compiling the software), since they could expect that >> > if packages can be disabled, that this will be done via an option with a >> > name which always follows the same scheme. >> >> I totally agree with that but I think it does not implies this has to be >> done by builtin find_package/add_subdirectory ? > > Well, it doesn't have to. > But if packagers requested this for something in KDE, they will also want this > for non-KDE projects. > And I see no reason why this shouldn't be the default for _every_ non-REQUIRED > package. > This would make the options available for cmake-based projects more > consistent. > This issue comes up regularly from new users. > > So, I don't see a reason why such an option should not be the default > behaviour and why I should rely on an external extension. Again I agree for find_package since the extra behavior seems backward compatible, (I need more time to think about it) you'll have to take care of name collision with existing user defined OPTION though. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Monday, June 06, 2011 03:37:16 PM Brad King wrote:
> On 06/06/2011 03:56 AM, Alexander Neundorf wrote:
> > On Saturday, June 04, 2011 10:24:52 AM Alexander Neundorf wrote:
> >> Hi,
> >>
> >> one feature which all KDE developers are used to and which is also used
> >> by qmake when building Qt is "automoc".
> >>
> >> This means that you don't have to write
> >> qt4_wrap_cpp(srcs ${filesToBeMoced})
> >>
> >> but instead you simply do
> >> kde4_add_executable(hello ${srcs})
> >> and everything including moc is handled automatically.
>
> I agree with Nico's response that this is too specific to integrate into
> CMake itself. That level of automagic processing puts too much inside
> the add_executable and add_library commands. This kind of customization
> belongs in macros.
>
> > Yesterday we finished porting our automoc away from Qt to pure STL/cmsys.
> > It is now a small executable of 300kb and linking to nothing special.
> > It is also BSD-licensed.
>
> Great! I suggest you package this in a distribution that provides the
> executable and CMake macros to use it:
That's already the current state, and developers are not happy with it.
They don't know about it or adding yet another dependency to the build is a
problem for them, e.g. due to strict policies at work.
I do not make this up, people come to me and complain that cmake doesn't do
it.
Everybody I talked to who is used to automoc from KDE or from qmake wants to
have it available directly in cmake.
Even the one Gnome guy who was in Randa was not happy with cmake for some Qt
projects he had because it didn't do automoc. So he felt cmake is too
complicated and stayed with qmake.
The same for about every KDE developer, i.e. hundreds.
We (me, you, Bill, Matthias Kretz, Andreas Hartmetz) talked about this
before, in march 2008. In a mail from March 18, 2008, you write:
--8<8<--8<-
Alexander Neundorf wrote:
> in kdelibs we have a tool "automoc", which is used to handle the moc files
> of Qt automatically, i.e. it parses the source files for Q_OBJECT etc. and
> runs moc as required.
> It is written using Qt 4 (QtCore only AFAIK).
> In order to make this usable also for Qt-only applications we (KDE) would
> like to move automoc out of kdelibs, the first step would be a separate svn
> module, or ideally directly into cmake.
Adding automoc would be a great motivation for people to use CMake for
Qt-based stuff.
...
> If those two things were met, would you accept it in cmake cvs as an
> additional tool or maybe also as a built-in command line command (as -E copy
> etc.) ?
If it is not too much code I'm not against accepting it. Bill?
...
-Brad
--8<8<--8<-
The "two things" are
- BSD licensing, we did that 3 years ago:
http://quickgit.kde.org/?p=automoc.git&a=commit&h=78fdba1e2d96bc45512531748ffb770cb1124798
-and porting to STL+cmsys, we did that now
Beside that, I didn't ask explicitely, but I'm sure without automoc cmake is
out of the game for becoming the buildsystem for Qt5 (because in Qt4 they do
automoc in qmake).
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory
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 Neundorf wrote: > >> [...] > >> > >> >> > What do you think about adding the keyword OPTIONAL to > >> >> > add_subdirectory ? > >> >> > > >> >> > Both have been proven useful, the one for find_package() especially > >> >> > for packagers. > >> >> > >> >> Ditto previous response. These commands are primitives. We should > >> >> not extend them with features unrelated to their basic purpose. > >> > > >> > While this is correct, it also keeps cmake a bit low-level. > >> > For this reason, we created such macros in KDE. > >> > Now our developers write stuff outside KDE, so either they can't use > >> > it, or they create copies of these files. > >> > This may be ok, but having 50 or 100 versions of these files and > >> > macros around in the net, some probably differing slightly, is also > >> > not a nice situation. > >> > >> Then it is possible to create a new CMake module, > >> > >> say > >> > >> UseEnhancedConfigure.cmake > >> > >> which could be included in CMake as a contributed module maintained by > >> KDE dev. This new module would define something like: > >> > >> optional_find_package(). > >> optional_add_subdirectory() > >> > >> this would make the feature available upstream, thus available outside > >> KDE and does not add extra feature to builtin configure. > > > > 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 ? > > Our e-mails crossed each-other. > > Yes you are right default behavior of making find_package(...without > REQUIRED) This is a different story for add_subdirectory. Yes, for me adding this to find_package() is the more important and more general useful one. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 6/8/2011 2:59 PM, Alexander Neundorf wrote: The "two things" are - BSD licensing, we did that 3 years ago: http://quickgit.kde.org/?p=automoc.git&a=commit&h=78fdba1e2d96bc45512531748ffb770cb1124798 -and porting to STL+cmsys, we did that now Beside that, I didn't ask explicitely, but I'm sure without automoc cmake is out of the game for becoming the buildsystem for Qt5 (because in Qt4 they do automoc in qmake). Alex I think it would be a good idea to have automoc support in CMake. -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Wednesday, June 08, 2011 12:59:36 pm Alexander Neundorf wrote:
> On Monday, June 06, 2011 03:37:16 PM Brad King wrote:
> > On 06/06/2011 03:56 AM, Alexander Neundorf wrote:
> > > On Saturday, June 04, 2011 10:24:52 AM Alexander Neundorf wrote:
> > >> Hi,
> > >>
> > >> one feature which all KDE developers are used to and which is also
> > >> used by qmake when building Qt is "automoc".
> > >>
> > >> This means that you don't have to write
> > >> qt4_wrap_cpp(srcs ${filesToBeMoced})
> > >>
> > >> but instead you simply do
> > >> kde4_add_executable(hello ${srcs})
> > >> and everything including moc is handled automatically.
> >
> > I agree with Nico's response that this is too specific to integrate into
> > CMake itself. That level of automagic processing puts too much inside
> > the add_executable and add_library commands. This kind of customization
> > belongs in macros.
> >
> > > Yesterday we finished porting our automoc away from Qt to pure
> > > STL/cmsys. It is now a small executable of 300kb and linking to
> > > nothing special. It is also BSD-licensed.
> >
> > Great! I suggest you package this in a distribution that provides the
>
> > executable and CMake macros to use it:
> That's already the current state, and developers are not happy with it.
> They don't know about it or adding yet another dependency to the build is a
> problem for them, e.g. due to strict policies at work.
>
> I do not make this up, people come to me and complain that cmake doesn't do
> it.
> Everybody I talked to who is used to automoc from KDE or from qmake wants
> to have it available directly in cmake.
>
> Even the one Gnome guy who was in Randa was not happy with cmake for some
> Qt projects he had because it didn't do automoc. So he felt cmake is too
> complicated and stayed with qmake.
> The same for about every KDE developer, i.e. hundreds.
>
> We (me, you, Bill, Matthias Kretz, Andreas Hartmetz) talked about this
> before, in march 2008. In a mail from March 18, 2008, you write:
>
> --8<8<--8<-
>
> Alexander Neundorf wrote:
> > in kdelibs we have a tool "automoc", which is used to handle the moc
> > files of Qt automatically, i.e. it parses the source files for Q_OBJECT
> > etc. and runs moc as required.
> > It is written using Qt 4 (QtCore only AFAIK).
> > In order to make this usable also for Qt-only applications we (KDE) would
> > like to move automoc out of kdelibs, the first step would be a separate
> > svn module, or ideally directly into cmake.
>
> Adding automoc would be a great motivation for people to use CMake for
> Qt-based stuff.
>
> ...
>
> > If those two things were met, would you accept it in cmake cvs as an
> > additional tool or maybe also as a built-in command line command (as -E
> > copy etc.) ?
>
> If it is not too much code I'm not against accepting it. Bill?
> ...
>
> -Brad
> --8<8<--8<-
>
> The "two things" are
> - BSD licensing, we did that 3 years ago:
> http://quickgit.kde.org/?p=automoc.git&a=commit&h=78fdba1e2d96bc45512531748
> ffb770cb1124798 -and porting to STL+cmsys, we did that now
>
> Beside that, I didn't ask explicitely, but I'm sure without automoc cmake
> is out of the game for becoming the buildsystem for Qt5 (because in Qt4
> they do automoc in qmake).
>
What if this was a generic tool that could scan code to handle custom
dependencies, with the ability to do two things: (re)generated dependent files
or (re)generate the file with dependencies (sounds like a make tool ;) ).
Don't some Visual Studio users do this type of custom build
phases/steps/thingy by creating an Add-In?
Would that be an automoc equivalent if there was a macro that gave it the
rules for generating the dependencies?
Also, (a long outstanding bug), a Qt .qrc file has dependencies specified in
xml, which should be handled at build time. Right now, the best we can do is
handle it at configure time, so we end up missing the regeneration of the
source file from the .qrc file sometimes or the build rules becomes invalidated
with source changes.
It seems an extra tool is needed at build time to handle qrc files correctly,
and I'm wondering if a generic tool could handle both this and the autmoc.
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 6/8/2011 3:33 PM, Clinton Stimpson wrote: > It seems an extra tool is needed at build time to handle qrc files correctly, > and I'm wondering if a generic tool could handle both this and the autmoc. It is not possible to implement custom build-time dependency scanning in VS IDE projects without creating some kind of VS plugin that defines a new language. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 6/8/2011 2:59 PM, Alexander Neundorf wrote: > The "two things" are > - BSD licensing, we did that 3 years ago: > http://quickgit.kde.org/?p=automoc.git&a=commit&h=78fdba1e2d96bc45512531748ffb770cb1124798 > > -and porting to STL+cmsys, we did that now Great. Please push a topic to the stage for review. Don't merge it to 'next' yet though. Thanks, -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On 06/08/2011 09:24 PM, Bill Hoffman wrote: > On 6/8/2011 2:59 PM, Alexander Neundorf wrote: > >> >> The "two things" are >> - BSD licensing, we did that 3 years ago: >> http://quickgit.kde.org/?p=automoc.git&a=commit&h=78fdba1e2d96bc45512531748ffb770cb1124798 >> >> -and porting to STL+cmsys, we did that now >> >> Beside that, I didn't ask explicitely, but I'm sure without automoc >> cmake is >> out of the game for becoming the buildsystem for Qt5 (because in Qt4 >> they do >> automoc in qmake). >> >> Alex >> > I think it would be a good idea to have automoc support in CMake. > > -Bill Although this is not really my call, here my thoughts: While I share some of the concerns that this is a very specialist tool of little use in general, but considering the importance of Qt, the strong coupling between KDE and CMake and finally the possibility of CMake becoming the QMake replacement, I think this makes a strong case for an exception here. So, +1 from me. Michael ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory
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 packages. These are well-defined primitives. I don't want to change this. http://en.wikipedia.org/wiki/Law_of_Demeter > So, I don't see a reason why such an option should not be the default > behaviour and why I should rely on an external extension. With that goal in mind I see no reason not to do this in a module that comes with CMake: include(OptionalFindPackage) optional_find_package(XYZ) This will keep the additional features out of the main command and provide a separate place to document them. If it turns out that the way the feature is implemented isn't that clean we can easily create a new macro with a new name. -Brad ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory
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 think about adding the keyword OPTIONAL to >> >> > add_subdirectory ? >> >> > >> >> > Both have been proven useful, the one for find_package() especially >> >> > for packagers. >> >> >> >> Ditto previous response. These commands are primitives. We should not >> >> extend them with features unrelated to their basic purpose. >> > >> > While this is correct, it also keeps cmake a bit low-level. >> > For this reason, we created such macros in KDE. >> > Now our developers write stuff outside KDE, so either they can't use it, >> > or they create copies of these files. >> > This may be ok, but having 50 or 100 versions of these files and macros >> > around in the net, some probably differing slightly, is also not a nice >> > situation. >> >> Then it is possible to create a new CMake module, >> >> say >> >> UseEnhancedConfigure.cmake >> >> which could be included in CMake as a contributed module maintained by KDE >> dev. This new module would define something like: >> >> optional_find_package(). >> optional_add_subdirectory() >> >> this would make the feature available upstream, thus available outside KDE >> and does not add extra feature to builtin configure. > > 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 have to confess that I never called find_package() without REQUIRED, and I can't think about any use case right now. -Nico ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Wed, Jun 8, 2011 at 1:35 PM, Brad King wrote: > On 6/8/2011 3:33 PM, Clinton Stimpson wrote: > > It seems an extra tool is needed at build time to handle qrc files > correctly, > > and I'm wondering if a generic tool could handle both this and the > autmoc. > > It is not possible to implement custom build-time dependency > scanning in VS IDE projects without creating some kind of > VS plugin that defines a new language. > > -Brad > ___ > cmake-developers mailing list > cmake-developers@cmake.org > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers > I'm just hearing about this automoc thing. I'm wondering if whatever mechanism that is used to handle the dependency generation could be used for FindCUDA.cmake. Currently I have to compute the dependencies using 'nvcc -M' and then adding those dependencies explicitly through the add_custom_command that generates the output from the CUDA source. Any thoughts? James ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012258]: include_directories(SYSTEM ...) not functional with GNU Makefiles
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12258 == Reported By:Campbell Barton Assigned To: == Project:CMake Issue ID: 12258 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-06-09 00:42 EDT Last Modified: 2011-06-09 00:42 EDT == Summary:include_directories(SYSTEM ...) not functional with GNU Makefiles Description: There were some system headers giving warnings compiling on linux, since I like to have warnings as errors, and not edit system headers, I used: include_directories(SYSTEM dir1 dir2 ...) ... for system directories only. However this does not result in -isystem being used in C because GNU.cmake does not set: set(CMAKE_INCLUDE_SYSTEM_FLAG_C "-isystem ") ... as it does for C++. I tried adding this directly after the project(), call (beforehand it fails to have any effect): if(CMAKE_COMPILER_IS_GNUCC) if(NOT APPLE) set(CMAKE_INCLUDE_SYSTEM_FLAG_C "-isystem ") endif() endif() So now it almost works, but I've noticed that If "include_directories(SYSTEM" is called after a non system include, ALL includes then use -isystem. Putting "include_directories(SYSTEM" first mostly works out OK, but I found a few cases where the order isn't so easy to set in our own CMakeLists.txt and still incorrectly uses -isystem where it shouldn't. Also found using the BEFORE / AFTER arguments to include_directories( doesn't make any difference to the use of -isystem. Is this a known problem or is there a way to get this working? == Issue History Date ModifiedUsername FieldChange == 2011-06-09 00:42 Campbell BartonNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
Clinton Stimpson wrote:
> On Wednesday, June 08, 2011 12:59:36 pm Alexander Neundorf wrote:
> > Beside that, I didn't ask explicitely, but I'm sure without automoc
> > cmake
> > is out of the game for becoming the buildsystem for Qt5 (because in Qt4
> > they do automoc in qmake).
>
> What if this was a generic tool that could scan code to handle custom
> dependencies, with the ability to do two things: (re)generated dependent
> files or (re)generate the file with dependencies (sounds like a make tool
> ;) ). Don't some Visual Studio users do this type of custom build
> phases/steps/thingy by creating an Add-In?
>
> Would that be an automoc equivalent if there was a macro that gave it the
> rules for generating the dependencies?
>
> Also, (a long outstanding bug), a Qt .qrc file has dependencies specified in
> xml, which should be handled at build time.
Isn't there already a build-time scanner to add dependencies? Those C/C++ files
need to be scanned to identify header dependencies which may change between
build runs also, no? So isn't this all about the same stuff? And for automoc
it's basically only a special case of this since this is also an include, just
one with a special pattern that adds additional dependencies.
I'm all in favor of a generic solution. So maybe we could step back and look
from a slightly greater distance at this. What would such a scanner need to
know? And what does it need to tell CMake to run properly?
Tell CMake:
-which source types it wants to pass (C/C++/Java/ASM/other/*)
-if it cares for header files
-to avoid tokenizing all files in all scanners a pattern to look for. If that
pattern is empty every file is passed to the scanner, otherwise only those
where at least one matches that pattern
-a flag if only matching lines should be send to the scanner (greatly reducing
computation time)
What it would return:
-for every file passed a list of files this one would depend on (testcases to
reject: file depending on itself, introducing simple loops)
That would work out for the qrc and header scanner as the files they depend on
are usually already there or defined by some target. This would not be enough
for the automoc case since someone needs to create the targets that generates
the moc_foo.cxx or foo.moc. So the scanner needs to be able to return
additional CMake code that would be parsed and used as if it was defined right
before the library/executable we try to create.
The next step would be to think about how people could come up with additions.
Say I want to write a scanner for some language. Must it be C++ code? Or can
this somehow be hooked into CMake just as CMake script? How would that go?
This way we could implement the whole automoc stuff just this way.
Alex, would this be a sufficient description for automoc?
language: C++
header files: only
pattern: Q_OBJECT
result files: none (will be handled by the usual include scanner of the C++
file)
result code: ADD_CUSTOM_TARGET(... ${QT_MOC_EXECUTABLE} ...)
Eike
signature.asc
Description: This is a digitally signed message part.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory
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 otherwise. Or just: build without some feature if a package is not availble. Eike signature.asc Description: This is a digitally signed message part. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automoc in cmake
On Thursday 09 June 2011, Rolf Eike Beer wrote:
> Clinton Stimpson wrote:
> > On Wednesday, June 08, 2011 12:59:36 pm Alexander Neundorf wrote:
> > > Beside that, I didn't ask explicitely, but I'm sure without automoc
> > > cmake
> > > is out of the game for becoming the buildsystem for Qt5 (because in Qt4
> > > they do automoc in qmake).
> >
> > What if this was a generic tool that could scan code to handle custom
> > dependencies, with the ability to do two things: (re)generated dependent
> > files or (re)generate the file with dependencies (sounds like a make tool
> > ;) ). Don't some Visual Studio users do this type of custom build
> > phases/steps/thingy by creating an Add-In?
> >
> > Would that be an automoc equivalent if there was a macro that gave it the
> > rules for generating the dependencies?
> >
> > Also, (a long outstanding bug), a Qt .qrc file has dependencies specified
> > in xml, which should be handled at build time.
>
> Isn't there already a build-time scanner to add dependencies? Those C/C++
> files need to be scanned to identify header dependencies which may change
> between build runs also, no? So isn't this all about the same stuff? And
> for automoc it's basically only a special case of this since this is also
> an include, just one with a special pattern that adds additional
> dependencies.
>
> I'm all in favor of a generic solution.
Yes, me too.
> So maybe we could step back and
> look from a slightly greater distance at this. What would such a scanner
> need to know? And what does it need to tell CMake to run properly?
I didn't succeed in finding a more general picture.
Automoc does:
-scan all given source files for special #includes
-if such are found, run moc to create them
-make sure this happens before the including file is compiled
So, the problem is, that at cmake time it is not known which files will have
to be generated, so I can't use add_custom_command() to create rules for these
files.
Right now this is done by adding an extra target _automoc to every
target.
If I added a custom command for every source file, which would create
basically a timestamp file, and run automoc just on this source file, I would
get the mocs generated, and automoc only rerun if the source file changed, but
since the source file depends on the moc files which come from a rule which
depends on the source file, I would get a cyclic dependency I think:
add_custom_command(
OUTPUT .automoc
COMMAND automoc file.cpp -o file.automoc (..and the yet unknwown mocfiles)
DEPENDS file.cpp )
add_executable(hello main.cpp file.cpp file.automoc )
I can't remember whether we tried that approach too, but wouldn't his produce
a cycle in the dependencies ?
Alex
> Tell CMake:
> -which source types it wants to pass (C/C++/Java/ASM/other/*)
> -if it cares for header files
> -to avoid tokenizing all files in all scanners a pattern to look for. If
> that pattern is empty every file is passed to the scanner, otherwise only
> those where at least one matches that pattern
> -a flag if only matching lines should be send to the scanner (greatly
> reducing computation time)
>
> What it would return:
> -for every file passed a list of files this one would depend on (testcases
> to reject: file depending on itself, introducing simple loops)
>
> That would work out for the qrc and header scanner as the files they depend
> on are usually already there or defined by some target. This would not be
> enough for the automoc case since someone needs to create the targets that
> generates the moc_foo.cxx or foo.moc. So the scanner needs to be able to
> return additional CMake code that would be parsed and used as if it was
> defined right before the library/executable we try to create.
But this has to happen at build time, not cmake time, since the #include "moc"
can be added without touching the cmake files.
> The next step would be to think about how people could come up with
> additions. Say I want to write a scanner for some language. Must it be C++
> code? Or can this somehow be hooked into CMake just as CMake script? How
> would that go? This way we could implement the whole automoc stuff just
> this way.
>
> Alex, would this be a sufficient description for automoc?
>
> language: C++
> header files: only
No, Q_OBJECT can also be in cpp-files.
> pattern: Q_OBJECT
>
> result files: none (will be handled by the usual include scanner of the C++
> file)
> result code: ADD_CUSTOM_TARGET(... ${QT_MOC_EXECUTABLE} ...)
See the issue above, this can change at build time, so cmake does not rerun.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding argument "OPTIONAL" to find_package() and add_subdirectory
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 have to confess that I never called find_package() without REQUIRED, > and I can't think about any use case right now. E.g. in KDE many packages are optional, if they are not found, the program is built without the feature which that package would have provided. The same for many other projects. E.g. Qt too has a lot of switches at configure-time. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
