On Thursday 10 May 2007 17:25, Trevor Kellaway wrote:
...
However, this has exposed a bug/issue, my list of dependencies includes
some custom commands, one of which has a non-standard language extension
.lint, this is causing a crash here:
cmTarget.cxx line 1252 in
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Trevor Kellaway
Sent: Thursday, May 10, 2007 4:33 AM
To: cmake@cmake.org
Subject: RE: [CMake] RE: CMake 2.4.1/VC71 Why the wierd project.dir
subdirs?
Also, is there are a way of recovering
Trevor Kellaway wrote:
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
Kishore,
Perhaps you could use GET_DIRECTORY_PROPERTY()?
GET_DIRECTORY_PROPERTY(INC_LIST INCLUDE_DIRECTORIES)
GET_DIRECTORY_PROPERTY(DEFS DEFINITIONS)
Thanks, I don't know how I missed this one.
- TrevK
___
CMake mailing list
CMake@cmake.org
Bill,
I'd personally like is some standard ways to get at *.obj locations
get_target_properties(foo PROPERTIES OBJECT_FILES objs)
I did make an attempt at this, and it worked well for
makefiles, but I had trouble with Xcode and visual studio I think...
Does that mean this is
Trevor Kellaway wrote:
Does that mean this is supported in the dev tree?
I tried this with cmake version 2.5-20070505 but it didn't work, I
also tried
GET_TARGET_PROPERTY (myobj myfile.c OBJECT_FILES)
What I really want to do is determine the object file for a specific
source file,
Bill,
It should work like this:
add_executable(foo foo.cxx)
get_target_property(objs foo OBJECT_FILES)
message(${objs})
Thanks, I was mistakenly calling it before the ADD_LIBRARY /
ADD_EXECUTABLE.
However, this has exposed a bug/issue, my list of dependencies includes
some custom
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Trevor Kellaway
Sent: Friday, May 11, 2007 12:15 AM
To: cmake@cmake.org
Subject: RE: [CMake] RE: CMake 2.4.1/VC71 Why the wierd project.dir
subdirs?
Kishore,
Perhaps you could use
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 somewhere else?
Cc: Bill Hoffman; cmake@cmake.org
Subject: Re: [CMake] RE: CMake 2.4.1/VC71 Why the wierd project.dir
subdirs?
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
-
From: Brad King [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 10:29 AM
To: Rob Mathews
Cc: Bill Hoffman; cmake@cmake.org
Subject: Re: [CMake] RE: CMake 2.4.1/VC71 Why the wierd project.dir
subdirs?
Rob Mathews wrote:
If I had fred.cpp in both the foo and bar directories,
then
foo
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 project.dir to the path doesn't get you
anything.
It does. E.g. you can use the same source file in two different targets
King; cmake@cmake.org; Bill Hoffman
Subject: Re: [CMake] RE: CMake 2.4.1/VC71 Why the wierd project.dir
subdirs?
It's not project.dir, it's library.dir.
Brad's talking about the same source file included in two different
libraries (libA and libB), not two different configurations (Debug
Rob Mathews wrote:
Right, sorry, technically it is library.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.
]
Sent: Wednesday, May 09, 2007 11:32 AM
To: Rob Mathews
Cc: David Cole; cmake@cmake.org; Bill Hoffman
Subject: Re: [CMake] RE: CMake 2.4.1/VC71 Why the wierd project.dir
subdirs?
Rob Mathews wrote:
Right, sorry, technically it is library.dir. Visual Studio just
confuses things by calling
Rob Mathews wrote:
Seems pretty clear that it returns project.dir and sets
IntermediateDirectory to it. Thus you would get
IntermediateDirectory=project.dir
and since Visual Studio interpretes that relative path as relative to
the project dir, you get
project/project.dir/Debug
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
2.4.1/VC71 Why the wierd project.dir
subdirs?
Rob Mathews wrote:
Seems pretty clear that it returns project.dir and sets
IntermediateDirectory to it. Thus you would get
IntermediateDirectory=project.dir
and since Visual Studio interpretes that relative path as relative to
the project dir, you
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/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
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 or
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
22 matches
Mail list logo
