015 10:21 AM
To: Daniel Schepler
Cc: cmake
Subject: Re: [CMake] [cmake-developers] CMake IR
On Fri, Jul 31, 2015 at 11:44 AM, Daniel Schepler
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:
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 www.kitware.co
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 '\' _builds/CMakeCache.txt
B:STRING=There is no A
I'm not saying cache is a bad idea, I'm just saying that whe
On Fri, Jul 31, 2015 at 11:44 AM, Daniel Schepler
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"))
>>SET(CMAKE_BUILD_TYPE ${CMAKE_B
: [CMake] [cmake-developers] CMake IR
On Fri, Jul 31, 2015 at 11:33 AM, Ruslan Baratov
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
On Fri, Jul 31, 2015 at 11:43 AM, Bill Hoffman 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 could be done witho
On 7/31/2015 12:33 PM, Ruslan Baratov wrote:
> rm -rf _builds
> cmake -H. -B_builds
> cmake -H. -B_builds -DA=ON
> grep '\' _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'
On Fri, Jul 31, 2015 at 11:33 AM, Ruslan Baratov
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 example:
>
>
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 2:05 AM, Nagy-Egri Máté Ferenc 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
> generators
>
>
> 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 f
@all:
Thank you folks for the input and the active discussion (not shifting into
flame and troll wars).
@Dave&Dan:
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 SHOUL
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
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,
fin
On Jul 30, 2015, at 11:56 AM, Dan Kegel wrote:
>
> Am 30.07.2015 10:15 vorm. schrieb "Bill Hoffman" :
> >
> > 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 s
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
Am 30.07.2015 10:15 vorm. schrieb "Bill Hoffman" :
>
> 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, bu
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 store
On Thu, Jul 30, 2015 at 9:30 AM, David Cole 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 general case.
They p
json is SOOO much sexier than XML. ;-)
On Thu, Jul 30, 2015 at 10:10 AM, Dan Kegel 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 pro
>> 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 (
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 don't
23 matches
Mail list logo
