Writing to the list since some of you may find a script useful that I
have been developing for a while now.
I'm using this script to help maintain source files for inkscape
~2000 files, and blender3d ~4000 files.
With large, portable projects is its hard to keep track of all files
on an active cod
On 06/22/2011 01:25 AM, J Decker wrote:
[...]
>
> just an observation ; gcc can generate dependancies as it is
> compiling, if these dependancies are included in make with
>
> -include file.depends.d
>
> then it doesn't fail during first build when there is none; anyhow
> that removes the nessec
On Tue, Jun 21, 2011 at 4:18 AM, David Cole wrote:
> On Tue, Jun 21, 2011 at 5:11 AM, J Decker wrote:
>>
>> Okay I have many many projects and targets using cmake to build them.
>>
>> I target openwatcom stock install, mingw stock install, and vs2010
>> stock install + cmake + my sources
>>
>> Of
Since I got no feedback, I assume it's a bug. I've filed it here:
0012295: LINK_FLAGS_RELEASE has no effect on static libraries for MSVC
generators
http://www.cmake.org/Bug/view.php?id=12295
On Mon, Jun 13, 2011 at 11:50 AM, Ben Medina wrote:
> Hello all,
>
> I'm using CMake 2.8.4 and am seeing
On 2011-06-21 08:28-0400 Brad King wrote:
On 06/17/2011 04:59 PM, Eric Noulard wrote:
OK I have the same behavior on my box using your example.
I did open a bug report:
http://public.kitware.com/Bug/view.php?id=12284
I posted an explanation here:
http://www.cmake.org/Bug/view.php?id=12284#c
On Jun 21, 2011 11:29 PM, "David Cole" wrote:
>
> Good suggestion.
>
> In the meantime, please find the link to the documentation page on the
cmake "resources" web page:
>
> http://www.cmake.org/cmake/resources/resources.html
It's not the page I expect... I expected a link to the page
http://ww
Good suggestion.
In the meantime, please find the link to the documentation page on the cmake
"resources" web page:
http://www.cmake.org/cmake/resources/resources.html
Thanks,
David
On Tue, Jun 21, 2011 at 1:55 PM, Kishore Jonnalagadda <
kitts.mailingli...@gmail.com> wrote:
> Should not the
Should not the cmake help web page (
http://www.cmake.org/cmake/help/help.html) contain a link to the
documentation page?
--
Cheers,
Kishore
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/ope
On Tue, Jun 21, 2011 at 12:09 PM, Hugo Heden wrote:
> **
> Good day all,
>
> I am using ADD_TEST like this:
>
> ADD_TEST(
> nameOfMyTest
> ${CMAKE_CTEST_COMMAND}
> --build-and-test ${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR}
> --build-generator ${CMAKE_GENERATOR}
> --build-make
Good day all,
I am using ADD_TEST like this:
ADD_TEST(
nameOfMyTest
${CMAKE_CTEST_COMMAND}
--build-and-test ${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR}
--build-generator ${CMAKE_GENERATOR}
--build-makeprogram ${CMAKE_BUILD_TOOL}
--build-nocmake
--build-noclean
--bu
On Tuesday, June 21, 2011 06:59:25 am Stephen Kelly wrote:
> Hi,
>
> Thanks for the response. I've got a few followups.
>
> Clinton Stimpson wrote:
> >> The part that is not clear to me is this:
> >> > This
> >> > means when a project B then uses project A, these imported targets
> >> > must be c
2011/6/21 John R. Cary :
> On 6/21/11 6:28 AM, Brad King wrote:
>>
>> On 06/17/2011 04:59 PM, Eric Noulard wrote:
>>>
>>> OK I have the same behavior on my box using your example.
>>> I did open a bug report:
>>> http://public.kitware.com/Bug/view.php?id=12284
>>
>> I posted an explanation here:
>>
thank you
Am 21.06.2011 um 16:07 schrieb Michael Wild:
On 06/21/2011 03:31 PM, Ignaz Reicht wrote:
Dear CMake list,
when building external libraries such as ITK, VTK, etc. from source,
XCode 4.0.1 is not able to import the BuildType parameter set in
Cmake
2.8-4. When setting CMAKE_BUILD_TYPE
I updated the bug with this patch and some of the details from below.
Aaron C. Meadows
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Meadows, Aaron C.
Sent: Monday, June 20, 2011 5:17 PM
To: cmake@cmake.org
Subject: [CMake] Bug #12189
(link: http://public.kit
On 6/21/11 6:28 AM, Brad King wrote:
On 06/17/2011 04:59 PM, Eric Noulard wrote:
OK I have the same behavior on my box using your example.
I did open a bug report:
http://public.kitware.com/Bug/view.php?id=12284
I posted an explanation here:
http://www.cmake.org/Bug/view.php?id=12284#c26931
On 06/21/2011 03:31 PM, Ignaz Reicht wrote:
> Dear CMake list,
>
> when building external libraries such as ITK, VTK, etc. from source,
> XCode 4.0.1 is not able to import the BuildType parameter set in Cmake
> 2.8-4. When setting CMAKE_BUILD_TYPE = Release, still XCode uses Debug
> as build type.
Dear CMake list,
when building external libraries such as ITK, VTK, etc. from source,
XCode 4.0.1 is not able to import the BuildType parameter set in Cmake
2.8-4. When setting CMAKE_BUILD_TYPE = Release, still XCode uses Debug
as build type. Has someone else observed this behavior?
thank
On Tue, Jun 21, 2011 at 9:05 AM, Andrea Galeazzi wrote:
> **
> David Cole ha scritto:
>
> On Mon, Jun 20, 2011 at 6:11 AM, Kalev Lember wrote:
>
>> Could you please pull in the following commit from -next into next rc?
>> It fixes a regression with locating swig executable in FindSWIG module.
>>
David Cole ha scritto:
On Mon, Jun 20, 2011 at 6:11 AM, Kalev
Lember
wrote:
Could
you please pull in the following commit from -next into next rc?
It fixes a regression with locating swig executable in FindSWIG module.
commit b09ae90badc17d5102b273d2bcfe11ebe
Hi,
Thanks for the response. I've got a few followups.
Clinton Stimpson wrote:
>> The part that is not clear to me is this:
>> > This
>> > means when a project B then uses project A, these imported targets must
>> > be created again, otherwise e.g. "Qt4__QtCore" will be interpreted as
>> > name
On 06/17/2011 04:59 PM, Eric Noulard wrote:
> OK I have the same behavior on my box using your example.
> I did open a bug report:
> http://public.kitware.com/Bug/view.php?id=12284
I posted an explanation here:
http://www.cmake.org/Bug/view.php?id=12284#c26931
CPack recursively collects all *f
On Tue, Jun 21, 2011 at 5:11 AM, J Decker wrote:
> Okay I have many many projects and targets using cmake to build them.
>
> I target openwatcom stock install, mingw stock install, and vs2010
> stock install + cmake + my sources
>
> Often when I make a change to sack/includes/*.h everything rebui
Hi James,
Thanks you for feedback. See my comments:
> I dismissed the idea of using the cmake dependency scanner, because it was a
> makefile only solution. I wasn't interested in maintaining multiple code
> paths. It's much better for testing to have it work basically the same way
> everywhere
Okay I have many many projects and targets using cmake to build them.
I target openwatcom stock install, mingw stock install, and vs2010
stock install + cmake + my sources
Often when I make a change to sack/includes/*.h everything rebuilds
appropriately.
If I change a header in a library that's l
On 06/21/2011 10:51 AM, J Decker wrote:
> header files in directory change should cause rebuild?
> Doesn't cmake parse the c files for includes and auto build header
> dependancies?
Sorry, can you rephrase your question? Preferably using complete
sentences, so people are actually are able to fol
header files in directory change should cause rebuild?
Doesn't cmake parse the c files for includes and auto build header dependancies?
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensour
26 matches
Mail list logo