Hi,
I've succesfully installed a Dart server to use with CTest for a
continuous build dashboard. However, The update stage which updates
from a svn repository doesn't recover prior revision numbers to
populate the update.xml file and thus when parsed by the Dart server
the URL to see the diffs in
Ok, so I managed to ask two dumb questions in one day :P
I belatedly discovered that the flags in fact were being changed.
However, this brought up another question: does anyone know how to
force cmake/nmake to show you the actual flags used during
compilation? nmake /N just shows the cmake comma
I'd like to build several libraries with identical rules except for
the compiler flags. However setting the COMPILE_FLAGS property for
each target does not seem to work. For instance:
add_library(foo_mt STATIC ${SRCS})
set_target_properties(foo_mt PROPERTIES COMPILE_FLAGS "/MT")
add_library(foo_
Hi guys,
Comparing the output of --debug, I realyzed that the code is skipping the
TAG generation part if you chose to send results using XML and do not give a
time for the nightly to run.
It seems quit strange to me, as one might as well send
experimental/continuous/... build results through XML
Hi,
Ok, adding CTEST_START(...) in my ctest.cmake script make it a little bt
better. The xml files are created, but not in the usual directory (see
below) and the dart2 server fails parsing them.
Going deeper into the problem, I compared the output of the
Ctest -D Experimental -V
command and what
Alex,
> Unfortunatly, everything goes fine except the submission
> part. The //Testing/ folder is created at the
> configuration time, but the intermediate directory is not
> created and thus, the xml files are not present when Ctest
> try to send them.
Which intermediate directory? Please gi
Brandon,
> I'd personally like is some standard ways to get at *.obj locations
...
Seconded, I also have a case where I'd like to determine the location of
.obj files.
I could predict this most of the time until I started pulling in source
files from relative paths outside the CMakeLists.txt lib
On May 9, 2007, at 11:27 AM, Mielcarek, Donn wrote:
I thought of that, but seems to be more pain
then it's worth (also, other people here
didn't like the idea).
Now I'm thinking of modifying the cmake source
to make it do what I want.
I believe I would have to modify 3 things:
1) the name o
Hi guys,
I set up a dart 2 server (java) in a corner, and succesfully managed to send
reports to it using Cmake.
Now I would like to set up some nightly and continuous builds on several
different machines with differents options (libs version, static/debug,
...). For this , I need to go through s
2007/5/9, Mielcarek, Donn <[EMAIL PROTECTED]>:
I thought of that, but seems to be more pain
then it's worth (also, other people here
didn't like the idea).
Now I'm thinking of modifying the cmake source
to make it do what I want.
I believe I would have to modify 3 things:
1) the name of
Dan,
> Glad to see you are using Dart. I'm cross posting this on
> the Dart mailing list.
Thanks for the reply, Dart is great, keep up the good work.
Sorry about cross posting, with my focus on CMake I naturally posted
here, I'll join the Dart list as well.
> To clarify, I'll refer to the
On Wednesday 09 May 2007 00:48:25 Asmodehn Shade wrote:
> So here are my questions :
> - What is the status of supporting convenience libraries ? Anyone knows if
> / when this will be likely to work ?
I don't think the CMake team is keen on supporting such convenience libs, from
past messages on
...and I just answered my own question. I had to set the CMAKE_C_FLAGS
variables even though the project file template appears to use CXX
variables. I assume this is because the project only uses .c files.
Sorry for the spam.
/Andrew
On 5/9/07, Andrew MacDonald <[EMAIL PROTECTED]> wrote:
I have
Why CMake 2.4.1? Are you stuck with that version for some reason? Current
is CMake 2.4.6, and of course there's CMake CVS. Does the problem exist for
either of those?
Cheers,
Brandon Van Every
On 5/9/07, Rob Mathews <[EMAIL PROTECTED]> wrote:
Title says it all. No way to pass a list of extr
On 5/9/07, Rob Mathews <[EMAIL PROTECTED]> wrote:
I understand your point, but the Visual Studio itself doesn't really
support more than one project in one directory. Ok, you can force it via
tricks like this, but that's not the beaten path for most VC developers.
Whether most people do it o
I have been unable to change the setting of CMAKE_CXX_FLAGS added to a
vc6 project file. The other variables such as BUILD_INCLUDES and
EXTRA_DEFINES work properly. I've tried both of the following
set(CMAKE_CXX_FLAGS "foo")
set(CMAKE_CXX_FLAGS "foo" CACHE STRING "" FORCE)
The latter changes th
Eclipse should work with MinGW directly. However I also use wxWidgets and
building is easiest with Cygwin/MinGW or MSYS/MinGW, I choose the latter. I
wasn't aware that Eclipse was able to deal with Cygwin paths, this is a
similar issue and should be solvable. I will do some prodding ;-)
As a tem
Bill Hoffman wrote:
Joshua Jensen wrote:
Well, now that I know what it is, I'll just turn off the
MACOSX_BUNDLE flag for the time being. I'll watch CVS for a fix.
It is broken for all targets in CVS at the moment for some reason
I would recommend not using cvs...
Unfortunately, there are
I understand your point, but the Visual Studio itself doesn't really
support more than one project in one directory. Ok, you can force it via
tricks like this, but that's not the beaten path for most VC developers.
For example, the wizard always makes a new directory.
Rather, they are used to the
On 5/9/07, Bill Hoffman <[EMAIL PROTECTED]> wrote:
CMake does have a test suite that checks for most of this stuff. My
guess is that if you made that change something would fail. But if it
did not fail, that would not mean that it would not cause a problem,
just that we did not yet create the
Rob Mathews wrote:
Ah, ok, now that makes sense.
But if you *aren't* doing that.. then you don't need this.
A very simple cmake project would need that:
add_library(foo foo.c)
add_executable(bar bar.c)
target_link_libraries(bar foo)
This would create foo.vcproj and bar.vcproj in the same
On 5/8/07, Peter Visser <[EMAIL PROTECTED]> wrote:
Hello,
I'm using eclipse with mingw/msys. Eclipse scans the build output for
auto discovery of include paths and defines, which is very useful for auto
completion. I upgraded from CMake 2.4.3 to CMake 2.4.6 and this breaks the
auto discovery f
Ah, ok, now that makes sense.
But if you *aren't* doing that.. then you don't need this.
-Original Message-
From: Brad King [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 12:59 PM
To: Rob Mathews
Cc: David Cole; cmake@cmake.org; Bill Hoffman
Subject: Re: [CMake] RE: CMake 2.4.
Brandon Van Every wrote:
Anyone get the feeling that this debate would go away if the burden of
proof was raised to the level of demonstrating safety under a gigantic
test suite covering all weird options? If such a suite existed, then
Rob could tweak CMake as he likes and then run the tes
Joshua Jensen wrote:
Well, now that I know what it is, I'll just turn off the MACOSX_BUNDLE
flag for the time being. I'll watch CVS for a fix.
It is broken for all targets in CVS at the moment for some reason I
would recommend not using cvs...
As a follow up question... why is that step
On 5/9/07, Brad King <[EMAIL PROTECTED]> wrote:
Rob Mathews wrote:
> Seems pretty clear that it returns ".dir" and sets
> IntermediateDirectory to it. Thus you would get
>
> IntermediateDirectory=.dir
>
> and since Visual Studio interpretes that relative path as relative to
> the project dir, yo
Rob Mathews wrote:
> Seems pretty clear that it returns ".dir" and sets
> IntermediateDirectory to it. Thus you would get
>
> IntermediateDirectory=.dir
>
> and since Visual Studio interpretes that relative path as relative to
> the project dir, you get
>
> /.dir/Debug
> /.dir/Release
>
> etc o
I dunno. It seems pretty clear to me that this is the wa
std::string cmLocalVisualStudio7Generator::GetTargetDirectory(cmTarget&
target)
is called from here: (line 472 or so of VisualStudio7Generator, the
method cmLocalVisualStudio7Generator::WriteConfiguration)
// The intermediate directory nam
Bill Hoffman wrote:
Joshua Jensen wrote:
ersion of CMake are you using? Also, I don't think CMake has
anything to do with the clean target, it is managed by Xcode itself.
It does seems that this is currently broken in CVS, I am looking into
the issue. I have to figure out some way of testing
Joshua Jensen wrote:
ersion of CMake are you using? Also, I don't think CMake has
anything to do with the clean target, it is managed by Xcode itself.
I always forget the important stuff. I'm using latest CVS and the
latest version of Xcode.
It does seems that this is currently broken in
Bill Hoffman wrote:
Joshua Jensen wrote:
Upon using CMake with Xcode and instructing CMake to generate
application bundles, I've run into the following issues:
* When I make a change to a static library, the executable doesn't
relink. I have to rm it from the application bundle myself. Upon
Rob Mathews wrote:
> Right, sorry, technically it is .dir. Visual Studio just
> confuses things by calling a library a project.
>
> But my point still stands – the intermediate files in VisualStudio are
> already qualified by the library name, so adding another level is
> pointless in that case. T
I thought of that, but seems to be more pain
then it's worth (also, other people here
didn't like the idea).
Now I'm thinking of modifying the cmake source
to make it do what I want.
I believe I would have to modify 3 things:
1) the name of the Makefile, e.g. Makefile.FC4
2) the install script,
On 2007-05-09 08:18-0400 Bill Hoffman wrote:
Asmodehn Shade wrote:
PROJECT ( target CXX )
That's a problem right there. That form of the command assures you will not
get C support. Specify no language (which defaults to C and CXX) or else
specify both C and CXX.
Alan
__
Hi,
I'm having problems reusing a CMakeCache.txt file using
cmake-2.4.6-Darwin-universal for an out-of-source build for VTK on Mac
OSX - although I don't think this is Mac OSX specific as I've hit it on
other platforms in the past, but just worked around it by generating a
new CMakeCache.txt file
Right, sorry, technically it is .dir. Visual Studio just
confuses things by calling a library a project.
But my point still stands - the intermediate files in VisualStudio are
already qualified by the library name, so adding another level is
pointless in that case. The only case where I see it
On Wednesday 09 May 2007 10:30, Rob Mathews wrote:
> Nope. That's what the configurations are for, - ie, Debug, Release,
> RelWithDebInfo, for example.
>
> Just adding the string ".dir" to the path doesn't get you
> anything.
It does. E.g. you can use the same source file in two different targets
It's not .dir, it's .dir.
Brad's talking about the same source file included in two different
libraries (libA and libB), not two different configurations (Debug and
Release).
Another duplicate name case is when you have files named the same (in
different directories) but then included in the sam
Thanks.
As far as $(OutDir), I'm staring at a makefile that reads:
INCLUDE_DIRECTORIES("$(OutDir)" ) ## Release or Debug
ADD_DEFINITIONS(${STANDARD_DEFINES} )
LINK_LIBRARIES( ${DEPENDS_DB} PerfLib opends60.lib xp_base)
SET(LIBRARY_OUTPUT_PATH ${EXECUTABLE_OUTPUT_PATH} ) ## DL
Nope. That's what the configurations are for, - ie, Debug, Release,
RelWithDebInfo, for example.
Just adding the string ".dir" to the path doesn't get you
anything.
-Original Message-
From: Brad King [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 10:29 AM
To: Rob Mathews
Cc: Bil
Rob Mathews wrote:
> And $(OutDir)?
There isn't one. That's what LIBRARY_OUTPUT_PATH and
EXECUTABLE_OUTPUT_PATH are supposed to set. What are you doing with
$(OutDir)? There is probably another way to do it.
-Brad
> -Original Message-
> From: Bill Hoffman [mailto:[EMAIL PROTECTED]
>
So I guess the important question for me is, is there a knob somewhere
that can make it work the old way?
Otherwise I have to add a knob to get back the old behaviour ... because
I have other link lines in other non-CMake projects that depend on
particular locations for the .lib files ...
-O
Rob Mathews wrote:
> If I had fred.cpp in both the foo and bar directories,
> then
> foo/Debug/fred.obj
> and
> bar/Debug/fred.obj
> are different files, and so that works fine.
>
> Hmm ... you must be talking about support for the case where the
> intermediate directories are all off somewher
If I had fred.cpp in both the foo and bar directories,
then
foo/Debug/fred.obj
and
bar/Debug/fred.obj
are different files, and so that works fine.
Hmm ... you must be talking about support for the case where the
intermediate directories are all off somewhere else? That's doesn't seem
to be the
Rob Mathews wrote:
CMake seems to be generating intermediate directories called
.dir and placing the obj files under them.
Ie, if my project is foo, then /foo/foo.dir/*.obj
I look in the code and see that this derives from
cmLocalVisual7Generator.cxx, which reads as follows. (The "#if 0" is m
And $(OutDir)?
-Original Message-
From: Bill Hoffman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 9:59 AM
To: Rob Mathews
Cc: cmake@cmake.org
Subject: Re: [CMake] LIBRARY_OUTPUT_PATH, EXECUTABLE_OUTPUT_PATH broken
if CMake variables used.
Rob Mathews wrote:
> While we're at i
CMake seems to be generating intermediate directories called
.dir and placing the obj files under them.
Ie, if my project is foo, then /foo/foo.dir/*.obj
I look in the code and see that this derives from
cmLocalVisual7Generator.cxx, which reads as follows. (The "#if 0" is my
addition)
std::stri
Rob Mathews wrote:
While we're at it, I notice some other VC variables that have crept in.
What's the CMake equivalent for these VC variables:?
$(OutDir)
$(ConfigurationName)
${CMAKE_CFG_INTDIR}
CMAKE_INTDIR will be a -D on the command line. CMAKE_CFG_INTDIR will
be expanded to . for m
On Wednesday 09 May 2007 09:18, Mielcarek, Donn wrote:
> Is there a way to make cmake output to other then
> "Makefile" on Linux? e.g. output to something
> like Makefile.cmake?
No. Does it help if you build out-of-source, this way eventually existing
makefiles in the source tree will not be over
While we're at it, I notice some other VC variables that have crept in.
What's the CMake equivalent for these VC variables:?
$(OutDir)
$(ConfigurationName)
Thanks.
-Original Message-
From: Bill Hoffman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 8:11 AM
To: Rob Mathews
Cc:
Is there a way to make cmake output to other then
"Makefile" on Linux? e.g. output to something
like Makefile.cmake?
Thanks.
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Title says it all. No way to pass a list of extra include directories to
the MIDL tool because CMake doesn't generate the
AdditionIncludeDirectories tag for the MIDL tool.
The fix is in cmLocalVisualStudio7Generator.cxx, lines 589, insert this
code:
fout << "\t\t\t\tAdditionalIncludeDirectorie
PROJECT_BINARY_DIR - didn't see use it because I thought it was
something else. Tried it, it works. You'd want ${PROJECT_BINARY_DIR}/lib
though - otherwise the result seems to be missing a '/'
-Original Message-
From: Bill Hoffman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 8:
Asmodehn Shade wrote:
PROJECT ( target CXX )
When forcing the link language :
SET_TARGET_PROPERTIES(${project_name} PROPERTIES LINKER_LANGUAGE CXX)
I can see in my source that some of my .cc file became .c ...
Well it my be an error on my side, How ever I wonder how cmake works when
mixing C
Joshua Jensen wrote:
Upon using CMake with Xcode and instructing CMake to generate
application bundles, I've run into the following issues:
* When I make a change to a static library, the executable doesn't
relink. I have to rm it from the application bundle myself. Upon
digging through the
Rob Mathews wrote:
Ie, something like:
SET(LIBRARY_OUTPUT_PATH "$(SolutionDir)lib" CACHE PATH "Single output
directory for building all libraries." FORCE)
doesn't work any more because cmSystemTools::FileIsFullPath() thinks
that "$SolutionDir)lib" is a relative path && prepends the project
l
On Wed, 9 May 2007 00:48:25 +0200
Asmodehn Shade <[EMAIL PROTECTED]> wrote:
> Hello everyone,
>
> I've seen in the FAQ and mailing list, that CMake doesnt support convenience
> libraries right now.
> I was trying to set up a set of cmake files to help in builds, when the
> directory hierarchy i
57 matches
Mail list logo
