On 9/20/2011 1:26 AM, Alexander Neundorf wrote:
set(CMAKE_INCLUDE_CURRENT_DIR ON) automatically adds the current source dir
and the current binary dir for each directory which has a target as include
directory.
This is a bit more than necessary for automoc.
For automoc for every target which nee
On Sunday, September 18, 2011 07:11:58 PM Marcus D. Hanwell wrote:
> On Sun, Sep 18, 2011 at 6:39 AM, Alexander Neundorf
wrote:
> > On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote:
> >> Stephen Kelly writes:
> >> > Alexander Neundorf wrote:
> >> >
> >> >
> >> > Would it be poss
On Sun, Sep 18, 2011 at 6:39 AM, Alexander Neundorf wrote:
> On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote:
>> Stephen Kelly writes:
>> > Alexander Neundorf wrote:
>> >
>> >
>> > Would it be possible to make CMAKE_AUTOMOC imply
>> > CMAKE_INCLUDE_CURRENT_DIR?
>> >
>> > All the b
On Saturday, September 17, 2011 07:16:28 PM Stephen Kelly wrote:
> Stephen Kelly writes:
> > Alexander Neundorf wrote:
> >
> >
> > Would it be possible to make CMAKE_AUTOMOC imply
> > CMAKE_INCLUDE_CURRENT_DIR?
> >
> > All the best,
> >
> > Steve.
>
> Is it still possible to consider this? It
Stephen Kelly writes:
>
> Alexander Neundorf wrote:
>
>
> Would it be possible to make CMAKE_AUTOMOC imply CMAKE_INCLUDE_CURRENT_DIR?
>
> All the best,
>
> Steve.
>
Is it still possible to consider this? It's not ideal that you have to do this:
set(CMAKE_AUTOMOC ON)
set(CMAKE_INCLUDE_CURR
Looks like the bootstrap test is failing:
http://www.cdash.org/CDash/viewConfigure.php?buildid=1438622
you need to wrap the moc stuff with this:
#if defined(CMAKE_BUILD_WITH_CMAKE)
-Bill
___
cmake-developers mailing list
cmake-developers@cmake.org
ht
On Tue, Aug 16, 2011 at 5:47 PM, Alexander Neundorf wrote:
> On Tuesday 16 August 2011, David Cole wrote:
>
>> 2011/8/16 Alexander Neundorf :
>
>> > On Tuesday 16 August 2011, Alexander Neundorf wrote:
>
>> >> On Tuesday 16 August 2011, Alexander Neundorf wrote:
>
>> >>
>
>> >> ...
>
>> >>
>
>> >>
On Tuesday 16 August 2011, David Cole wrote:
> 2011/8/16 Alexander Neundorf :
> > On Tuesday 16 August 2011, Alexander Neundorf wrote:
> >> On Tuesday 16 August 2011, Alexander Neundorf wrote:
> >>
> >> ...
> >>
> >> > There is now a branch AutomocForQt on the cmake stage.
> >> >
> >> > Docs and
Alexander Neundorf wrote:
> On Tuesday 16 August 2011, Alexander Neundorf wrote:
>> On Tuesday 16 August 2011, Alexander Neundorf wrote:
>> ...
>>
>> > There is now a branch AutomocForQt on the cmake stage.
>> > Docs and a test are still missing.
>>
>> It has a test now. Docs are still missing.
2011/8/16 Alexander Neundorf :
> On Tuesday 16 August 2011, Alexander Neundorf wrote:
>
>> On Tuesday 16 August 2011, Alexander Neundorf wrote:
>
>> ...
>
>>
>
>> > There is now a branch AutomocForQt on the cmake stage.
>
>> > Docs and a test are still missing.
>
>>
>
>> It has a test now. Docs are
On Tuesday 16 August 2011, Alexander Neundorf wrote:
> On Tuesday 16 August 2011, Alexander Neundorf wrote:
> ...
>
> > There is now a branch AutomocForQt on the cmake stage.
> > Docs and a test are still missing.
>
> It has a test now. Docs are still missing.
Now it also has docs.
I haven't mer
On Tuesday 16 August 2011, Alexander Neundorf wrote:
...
> There is now a branch AutomocForQt on the cmake stage.
> Docs and a test are still missing.
It has a test now. Docs are still missing.
Alex
___
cmake-developers mailing list
cmake-developers@cma
On Saturday 04 June 2011, 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_
On Thursday, June 09, 2011 01:23:09 am Alexander Neundorf wrote:
> On Wednesday 08 June 2011, Brad King 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=78fdb
On 6/9/2011 8:47 AM, Alexander Neundorf wrote:
> So, if I would create a dummy foo.automoc file from automoc, and added this
> to
> the target, this would make sure that any files created as "side-effects" of
> this custom command would already exist when any source files are compiled ?
Yes. I
On Thursday 09 June 2011, Brad King wrote:
> On 6/9/2011 4:12 AM, Alexander Neundorf wrote:
> > AFAIK depending on generated files via the #include does not work/is not
> > reliable (that's why generated files need to be added to the target).
>
> For the Makefile generators, each target builds in
On 6/9/2011 4:12 AM, Alexander Neundorf wrote:
> AFAIK depending on generated files via the #include does not work/is not
> reliable (that's why generated files need to be added to the target).
For the Makefile generators, each target builds in three steps:
(1) Generate all custom command output
> On Thursday 09 June 2011, Alexander Neundorf wrote:
> ...
>> At build time, the logic is complex enough and it also has to be really
>> fast so that this should IMO be done in the C++.
>> It could either be a -E automoc option, or a -P
>> CMakeAutomoc.cmake script, which then calls a new automoc
On Thursday 09 June 2011, Rolf Eike Beer wrote:
> > 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
On Thursday 09 June 2011, Alexander Neundorf wrote:
...
> At build time, the logic is complex enough and it also has to be really
> fast so that this should IMO be done in the C++.
> It could either be a -E automoc option, or a -P
> CMakeAutomoc.cmake script, which then calls a new automoc() funct
Alex Neundorf wrote:
> On Thursday 09 June 2011, Rolf Eike Beer wrote:
>> Clinton Stimpson wrote:
>> > On Wednesday, June 08, 2011 12:59:36 pm Alexander Neundorf wrote:
>> So maybe we could step back and
>> look from a slightly greater distance at this. What would such a scanner
>> need to know? A
On Wednesday 08 June 2011, Brad King 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=78fdba1e2d96bc455125317
> > 48ffb770cb1124798 -and porting to STL+cmsys, we did
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 (becaus
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
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
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
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 sta
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 withou
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
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 su
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 i
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_w
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 simp
Hi,
IMHO, both proposals are too Qt/KDE specific to be integrated into
cmake this way. Maybe cmake could provide a more generic approach
like allowing you to run whatever dependency scanner at some stage in
the build process.
-Nico
On Saturday, June 4, 2011, Alexander Neundorf wrote:
> Hi,
>
>
34 matches
Mail list logo
