Re: [CMake] What is the proper way to handle additional non-object files generated by compilation?

On 2008-05-23 07:07+0200 Maik Beckmann wrote: Am Freitag 23 Mai 2008 01:08:46 schrieb Alan W. Irwin: On 2008-05-21 18:25-0700 Alan W. Irwin wrote: I am finally working again on the CMake language support for Ada (currently implemented just for the gcc gnatmake compiler). One of the issues is

Re: [CMake] Dealing with dll PATH on Windows

KSpam wrote: HS, On Thursday 22 May 2008 02:05:33 Hendrik Sattler wrote: KSpam schrieb: Using this add-in would require that I create a corresponding .slnenv file for each .sln file generated by CMake. In my case, the contents of the .slnenv files can be the same (I am just setting P

Re: [CMake] What is the proper way to handle additional non-object files generated by compilation?

Am Freitag 23 Mai 2008 01:08:46 schrieb Alan W. Irwin: > On 2008-05-21 18:25-0700 Alan W. Irwin wrote: > > I am finally working again on the CMake language support for Ada > > (currently implemented just for the gcc gnatmake compiler). One of the > > issues is the gnatmake compiler not only produc

Re: [CMake] What is the proper way to handle additional non-object files generated by compilation?

On 2008-05-21 18:25-0700 Alan W. Irwin wrote: I am finally working again on the CMake language support for Ada (currently implemented just for the gcc gnatmake compiler). One of the issues is the gnatmake compiler not only produces *.o object files but also *.ali (Ada library information) files

Re: [CMake] Bump -- CMAKE_INSTALL_PREFIX weirdness.

On 2008-05-22 16:36-0500 kent williams wrote: I'll ask this again. We use a build system that for better or worse, invokes cmake from a Makefile to configure ITK, VTK, KWWidgets etc. In other words we have a command invoked from gnu make that looks like this: cmake /scratch/kent/brains2/iplFr

[CMake] Bump -- CMAKE_INSTALL_PREFIX weirdness.

I'll ask this again. We use a build system that for better or worse, invokes cmake from a Makefile to configure ITK, VTK, KWWidgets etc. In other words we have a command invoked from gnu make that looks like this: cmake /scratch/kent/brains2/iplFreeware/unpackdir/Insight -DCMAKE_INSTALL_PREFIX:P

Re: [CMake] Dealing with dll PATH on Windows

HS, On Thursday 22 May 2008 02:05:33 Hendrik Sattler wrote: > KSpam schrieb: > > Using this add-in would require that I create a corresponding .slnenv > > file for each .sln file generated by CMake. In my case, the contents of > > the .slnenv files can be the same (I am just setting PATH). > > >

Re: [CMake] About CMakeLists.txt coding style

Philip Lowman wrote: On Fri, May 16, 2008 at 9:56 PM, Edson Tadeu <[EMAIL PROTECTED] > wrote: (Not even mentioning the indent style). It seems that there is a transition going on from uppercase to lowercase in the recent CMakeLists... I don't know what st

Re: [CMake] QTestlib CTest Integration

QTestLib has some overlapping functionality with CTest. What I've done is use CTest where they overlap. So in this example here http://doc.trolltech.com/4.2/qtestlib-tutorial1.html instead of using the QTEST_MAIN macro I use CMake's create_test_sourcelist macro. There is a little bit more code

Re: [CMake] [ctest] junit xml output

On Thu, May 22, 2008 at 9:46 AM, Mike Arthur <[EMAIL PROTECTED]> wrote: > On Thursday 22 May 2008 13:55:19 Doug Gregor wrote: >> We've been discussing exactly the same sort of thing for Boost, but >> with output from CTest going to Bitten (http://bitten.edgewall.org/). >> XSLT seems like an easy wa

Re: [CMake] [ctest] junit xml output

On Thursday 22 May 2008 13:55:19 Doug Gregor wrote: > We've been discussing exactly the same sort of thing for Boost, but > with output from CTest going to Bitten (http://bitten.edgewall.org/). > XSLT seems like an easy way to handle this transformation. Is this being done already by you guys or is

[CMake] QTestlib CTest Integration

I've been look for information about if CTest and QTestLib place nicely together (i.e. CTest can tell that QTestLib has done multiple tests and display that information) and only found some emails from a few years ago. Can anyone fill me in on this? Done some rather intense googling without much

Re: [CMake] [ctest] junit xml output

Am Donnerstag 22 Mai 2008 15:31:23 schrieb Bill Hoffman: > I suppose that would be myself and Ken. If you want to talk about major > changes we could move the discussion to cmake-developers: > > > http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers Huh, I didn't know it. __

Re: [CMake] [ctest] junit xml output

Maik Beckmann wrote: Am Montag 19 Mai 2008 13:22:21 schrieb Maik Beckmann: Hi, I thinking about working on ant's junit xml format as a secondary output format of ctest. This way it would be much more convenient to integrate ctest results into one of the java centric/compatible dashboards. [s

Re: [CMake] CMake questions

> Von: dizzy > On Thursday 22 May 2008 12:03:01 Oleg Puchinin wrote: > > Hello ! > > > > 2. How to build target with debug info ? > > There are several solutions here. A not very portable aproach is to add > whatever compiler flags you wish to the compile command used, using > cmake's > SET_TAR

Re: [CMake] CMake questions

On Thursday 22 May 2008 12:03:01 Oleg Puchinin wrote: > Hello ! > > I have two questions. > 1. How to add source files to target ? See the man page for "ADD_EXECUTABLE", basically when you add a target you have to specify the sources it's made of too. > 2. How to build target with debug info ?

Re: [CMake] [ctest] junit xml output

On Mon, May 19, 2008 at 5:02 AM, David Cole <[EMAIL PROTECTED]> wrote: > That's a great idea! Are cppunit and nunit output formats similar enough to > junit that they could all be done at once...? > > Feel free to submit a patch implementing this as a feature request in the > bug tracker... or to c

Re: [CMake] linking to .so's

On Wed, May 21, 2008 at 8:45 AM, Steven Van Ingelgem <[EMAIL PROTECTED]> wrote: > I have a question about how to link (via CMake) to specific .so's. > > I know I need to use target_link_libraries. But what happens then is > that the so is linked against the directory where it's in. > Is there a po

[CMake] Why is there no install(DIRECTORY dirs... COMPONENT OPTIONAL)?

The OPTIONAL argument can be passed to every other variant of the "install" command, but not the DIRECTORY version. Is there any particular reason for this limitation, or is it an oversight? I know I can get around the issue with install(FILES...) and a file(GLOB_RECURSE), but that's not quite as g

Re: [CMake] [ctest] junit xml output

> I think the xslt road is the best bet. A c++ code solution > would result in a > much higher complexity and most likely to a much higher > memory footprint. > > The xslt processor can be treated similar to the other tools > like cvs and svn, > which gives ctest the chance to do some error

Re: [CMake] Dealing with dll PATH on Windows

KSpam schrieb: Using this add-in would require that I create a corresponding .slnenv file for each .sln file generated by CMake. In my case, the contents of the .slnenv files can be the same (I am just setting PATH). What is the best way to accomplish generating a .slnenv file for each gener

[CMake] CMake questions

Hello ! I have two questions. 1. How to add source files to target ? 2. How to build target with debug info ? Thanks. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake

[CMake] Dealing with dll PATH on Windows

I have been searching for a convenient way to deal with PATH on Windows. Here are my requirements: 1) Multiple third party libraries, each with their own unique dll directory (i.e. no shared directory to dump dlls in) 2) Third party library locations can change (i.e. I want to upgrade lib FOO t

Re: [CMake] [ctest] junit xml output

Am Montag 19 Mai 2008 13:22:21 schrieb Maik Beckmann: > Hi, > > I thinking about working on ant's junit xml format as a secondary output > format of ctest. This way it would be much more convenient to integrate > ctest results into one of the java centric/compatible dashboards. [snip] > An optio