Ugh ! It gets messier. I'm beginning to understand why it is the way it
is. The cmake developers have probably already been round this loop and
decided it wasn't worth the effort :-)
On 1 May 2014 19:41, Nils Gladitz wrote:
> On 01.05.2014 20:38, Glenn Coombs wrote:
>
>> Okay, I think I unde
On 01.05.2014 20:38, Glenn Coombs wrote:
Okay, I think I understand what you're saying. Variables set in a
CMakeLists.txt file added by add_subdirectory are only visible in that
CMakeLists.txt and any further ones it adds via add_subdirectory. The
higher level CMakeLists.txt files would not h
Okay, I think I understand what you're saying. Variables set in a
CMakeLists.txt file added by add_subdirectory are only visible in that
CMakeLists.txt and any further ones it adds via add_subdirectory. The
higher level CMakeLists.txt files would not have the necessary visibility,
hence the need
On 2014-05-01 14:26, Nils Gladitz wrote:
On 01.05.2014 20:16, Matthew Woehlke wrote:
If CMAKE_BINARY_DIR were not cached, yes. But I don't think not
caching that is being suggested. It's not clear to me why the
*per-project* flavors need to be cached?
If they were regular instead of cache var
On Thu, May 1, 2014 at 11:26 AM, Nils Gladitz wrote:
> On 01.05.2014 20:16, Matthew Woehlke wrote:
>
>>
>> If CMAKE_BINARY_DIR were not cached, yes. But I don't think not caching
>> that is being suggested. It's not clear to me why the *per-project* flavors
>> need to be cached?
>>
>>
> If they w
On 01.05.2014 20:16, Matthew Woehlke wrote:
If CMAKE_BINARY_DIR were not cached, yes. But I don't think not
caching that is being suggested. It's not clear to me why the
*per-project* flavors need to be cached?
If they were regular instead of cache variables they would have scopes.
I guess
On Thu, May 1, 2014 at 2:16 PM, Matthew Woehlke
wrote:
> On 2014-05-01 13:35, John Drescher wrote:
>>>
>>> I thought they probably were. My question was really if the behaviour
>>> that
>>> results from that was desirable. I can't see any reason why they should
>>> be
>>> cached as they aren't u
On 2014-05-01 13:35, John Drescher wrote:
I thought they probably were. My question was really if the behaviour that
results from that was desirable. I can't see any reason why they should be
cached as they aren't user configurable variables. Would it break anything
badly if they were not stor
On Thu, May 1, 2014 at 1:54 PM, Glenn Coombs wrote:
> What I am saying is that project("foo") should internally execute the
> equivalent of set(foo_SOURCE_DIR "/path/to/source") rather than set(foo
> "/path/to/source" CACHE STRING). That way it would fail on every run if you
> referenced a projec
What I am saying is that project("foo") should internally execute the
equivalent of set(foo_SOURCE_DIR "/path/to/source") rather than set(foo
"/path/to/source" CACHE STRING). That way it would fail on every run if
you referenced a project source directory variable before you had done the
add_subdi
> I thought they probably were. My question was really if the behaviour that
> results from that was desirable. I can't see any reason why they should be
> cached as they aren't user configurable variables. Would it break anything
> badly if they were not stored in the cache ? It would result i
I thought they probably were. My question was really if the behaviour that
results from that was desirable. I can't see any reason why they should be
cached as they aren't user configurable variables. Would it break anything
badly if they were not stored in the cache ? It would result in more
c
On 2014-04-23 14:18, Glenn Coombs wrote:
Are the [Project name]_SOURCE_DIR variables being automatically stored in
the cmake cache?
Running 'grep _SOURCE_DIR CMakeCache.txt' would answer this question.
(And yes, they are.)
--
Matthew
--
Powered by www.kitware.com
Please keep messages on-to
I'm using cmake version 2.8.12.1 and have just encountered an issue with my
cmake setup where I was using the [Project name]_SOURCE_DIR variable in an
include_directories command and it was being ignored. In my top level
CMakeLists.txt I had:
project(blah)
add_subdirectory(foo)
add_subdirectory(
14 matches
Mail list logo