On 7/31/2015 12:33 PM, Ruslan Baratov wrote:
rm -rf _builds
cmake -H. -B_builds
cmake -H. -B_builds -DA=ON
grep '\B\' _builds/CMakeCache.txt
B:STRING=There is no A
I'm not saying cache is a bad idea, I'm just saying that when users hit
such kind of situations that's
On Fri, Jul 31, 2015 at 2:05 AM, Nagy-Egri Máté Ferenc cmake@cmake.org wrote:
I agree that JSON looks better. I have no fetish about XML and I could be
convinced on just about anything in the choice of the IR. The only important
point is that it SHOULD EXIST and be well defined. Hooking all the
: [CMake] [cmake-developers] CMake IR
On Fri, Jul 31, 2015 at 11:33 AM, Ruslan Baratov
ruslan_bara...@yahoo.com wrote:
I never use the GUI, and consider the cache an anti-feature there solely
to support GUI users. It complicates my life, and I'd love to see it go.
In what way do you think
On Fri, Jul 31, 2015 at 11:33 AM, Ruslan Baratov
ruslan_bara...@yahoo.com wrote:
I never use the GUI, and consider the cache an anti-feature there solely
to support GUI users. It complicates my life, and I'd love to see it go.
In what way do you think it is causing you trouble?
Here is an
On 30-Jul-15 20:36, Bill Hoffman wrote:
On 7/30/2015 11:56 AM, Dan Kegel wrote:
I believe the latter, but not the former.
I never use the GUI, and consider the cache an anti-feature there solely
to support GUI users. It complicates my life, and I'd love to see it
go.
It is certainly not there
On Fri, Jul 31, 2015 at 11:43 AM, Bill Hoffman bill.hoff...@kitware.com wrote:
Something like:
$CACHE{A}
Then, it would never be confused with the the variable A. However, getting
rid of the cache would not be something that could be done.
Having a cache for invariants is a good thing if it
On Fri, Jul 31, 2015 at 11:44 AM, Daniel Schepler
dschep...@scalable-networks.com wrote:
Here's another example from real life. Maybe I'm just being an idiot,
but this is what I had to do to set a default:
IF(DEFINED CMAKE_BUILD_TYPE AND (NOT ${CMAKE_BUILD_TYPE} STREQUAL None))
On 31-Jul-15 19:43, Bill Hoffman wrote:
On 7/31/2015 12:33 PM, Ruslan Baratov wrote:
rm -rf _builds
cmake -H. -B_builds
cmake -H. -B_builds -DA=ON
grep '\B\' _builds/CMakeCache.txt
B:STRING=There is no A
I'm not saying cache is a bad idea, I'm just saying that when
On 31-Jul-15 19:44, Daniel Schepler wrote:
This seems to work for me:
set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo)
By the way you need to set it before first 'project' command. Also it
will not have any effects for multi-config generators like Xcode or
Visual Studio.
--
Powered by
To: Daniel Schepler
Cc: cmake
Subject: Re: [CMake] [cmake-developers] CMake IR
On Fri, Jul 31, 2015 at 11:44 AM, Daniel Schepler
dschep...@scalable-networks.com wrote:
Here's another example from real life. Maybe I'm just being an idiot,
but this is what I had to do to set a default:
IF(DEFINED
As for the GUI editor of a project, it has occured to me (and others too)
that such a tool would be darn useful. If it were a seperate tool, I’d
still use it just about every day, but you are correct that this feature
would be best embedded into the IDE. I am actively engaged with the folk
@all:
Thank you folks for the input and the active discussion (not shifting into
flame and troll wars).
@DaveDan:
I agree that JSON looks better. I have no fetish about XML and I could be
convinced on just about anything in the choice of the IR. The only important
point is that it
On 07/29/2015 09:49 AM, Nagy-Egri Máté Ferenc via cmake-developers wrote:
*
The big selling point would be the ability to introduce arbitrary
front-ends to CMake, not just CMakelists.txt. Every developer could
choose an input language that suits their project/needs/skills.
I
The big selling point would be the ability to introduce arbitrary
front-ends to CMake, not just CMakelists.txt. Every developer could
choose an input language that suits their project/needs/skills.
I don't like that idea.
Many different languages would make supporting (as in
json is SOOO much sexier than XML. ;-)
On Thu, Jul 30, 2015 at 10:10 AM, Dan Kegel d...@kegel.com wrote:
The big selling point would be the ability to introduce arbitrary
front-ends to CMake, not just CMakelists.txt. Every developer could
choose an input language that suits
On Thu, Jul 30, 2015 at 9:30 AM, David Cole dlrd...@aol.com wrote:
json is SOOO much sexier than XML. ;-)
shiny, shiny json :-)
Agreed, json is not covered with ugly-stink. I like it and use it daily.
I'm not at all sure that stateless build languages are a win in the
multiplatform
On 7/30/2015 10:48 AM, Dan Kegel wrote:
I wouldn't mind getting rid of the cache, it's a bizarre concept that appears
to be a workaround for users who can't stand starting cmake from a script,
and it complicates my cmake scripts, but that's not a battle I'd like to wage.
No, it is how CMake
Disclaimer: My name is attached to the failed CMake/Lua attempt.
In principle, I like the idea of what you propose. However, in
practice, I think it might be too big and too ambitious.
Here are some quick thoughts I have:
- I am in the camp that I do not like the CMake language. And it is
often
On Wednesday, July 29, 2015 07:49:07 Nagy-Egri Máté Ferenc via cmake-
developers wrote:
...
I believe CMake is an invaluable tool, but it could do far better. 0/10
CMake users I’ve met say they are “happy” CMake users. The learning curve
is steep, and the skills gained are not reusable. CMake
Am 30.07.2015 10:15 vorm. schrieb Bill Hoffman bill.hoff...@kitware.com:
On 7/30/2015 10:48 AM, Dan Kegel wrote:
I wouldn't mind getting rid of the cache, it's a bizarre concept that
appears
to be a workaround for users who can't stand starting cmake from a
script,
and it complicates my
I think this topic addresses improving the greatest CMake's greatest weakness.
It would modularize the internals of CMake in a cleaner fashion
Good point. Having built part of a generator, I would appreciate cleaner
generator interfaces. That way it's clear what implementations are necessary to
On Jul 30, 2015, at 11:56 AM, Dan Kegel d...@kegel.com wrote:
Am 30.07.2015 10:15 vorm. schrieb Bill Hoffman bill.hoff...@kitware.com:
On 7/30/2015 10:48 AM, Dan Kegel wrote:
I wouldn't mind getting rid of the cache, it's a bizarre concept that
appears
to be a workaround for
On 7/30/2015 11:56 AM, Dan Kegel wrote:
I believe the latter, but not the former.
I never use the GUI, and consider the cache an anti-feature there solely
to support GUI users. It complicates my life, and I'd love to see it go.
It is certainly not there just for the GUI. Every try-compile,
23 matches
Mail list logo
