Re: [CMake] [cmake-developers] CMake IR
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 one of the reason why they said CMake is
not a good script language. Just like CMake before CMP0054: user see
`if(a STREQUAL b)` and think okay, 'a' is not equal to 'b' so this
condition is always false... nope!
OK, it is a bit confusing. One solution would be to treat the cache
variables with some sort of separate look up. Basically put all cache
stuff into its own namespace.
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.
-Bill
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 generators straight into the script interpreter is not good. Are you saying that cmake should switch from being imperative to being declarative? That's really quite a large change. I don’t quite understand resistance toward MS tech. Windows resides on +80% of PCs in the world, CMake already has VS and NMake generators… if there existed multiple input languages, I do not understand why one of them couldn’t be a native Windows script language. It's a free world, so if CMake was turned into a library or a JSON interface, of course you could write a binding in any language you choose. Those of us who remember Microsoft's past behavior (e.g. there was a great training presentation from Microsoft about how Microsoft evangelists should not consider themselves friends of developers, but rather remember that their goal was always to drive adoption of Microsoft tools, regardless of whether it was in the best interest of developers) may react suspiciously to any development that might lead to a Microsoft language being the preferred front end to a cross-platform tool. - Dan -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
This seems to work for me:
set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo)
--
Daniel Schepler
From: CMake [cmake-boun...@cmake.org] on behalf of Dan Kegel [d...@kegel.com]
Sent: Friday, July 31, 2015 9:38 AM
To: Ruslan Baratov
Cc: cmake; Bill Hoffman
Subject: Re: [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 it is causing you trouble?
Here is an example:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(Foo)
if(A)
set(B Hello A CACHE STRING Do we use A?)
else()
set(B There is no A CACHE STRING Do we use A?)
endif()
User thinks: okay, if I set A=ON I will have B equal to Hello A.
What user really have:
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 one of the reason why they said CMake is not a
good script language. Just like CMake before CMP0054: user see `if(a
STREQUAL b)` and think okay, 'a' is not equal to 'b' so this condition is
always false... nope!
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_BUILD_TYPE} CACHE STRING Choose the
type of build, options are: Debug Release RelWithDebInfo)
ELSE()
SET(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING Choose the type
of build, options are: Debug Release RelWithDebInfo FORCE)
ENDIF()
Can someone give me the proper one-line way to set a default for
CMAKE_BUILD_TYPE, or is this an authentic problem?
- Dan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [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 it is causing you trouble?
Here is an example:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(Foo)
if(A)
set(B Hello A CACHE STRING Do we use A?)
else()
set(B There is no A CACHE STRING Do we use A?)
endif()
User thinks: okay, if I set A=ON I will have B equal to Hello A.
What user really have:
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 one of the reason why they said CMake is not a
good script language. Just like CMake before CMP0054: user see `if(a
STREQUAL b)` and think okay, 'a' is not equal to 'b' so this condition is
always false... nope!
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_BUILD_TYPE} CACHE STRING Choose the
type of build, options are: Debug Release RelWithDebInfo)
ELSE()
SET(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING Choose the type
of build, options are: Debug Release RelWithDebInfo FORCE)
ENDIF()
Can someone give me the proper one-line way to set a default for
CMAKE_BUILD_TYPE, or is this an authentic problem?
- Dan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 just for the GUI. Every try-compile, find_library, find_program result is stored there as well. If you did this each time, it would be not only slow to re-run a build, but it might come up with different answers each time. If it went it would complicate your life even more. [...] In what way do you think it is causing you trouble? Here is an example: # CMakeLists.txt cmake_minimum_required(VERSION 3.0) project(Foo) if(A) set(B Hello A CACHE STRING Do we use A?) else() set(B There is no A CACHE STRING Do we use A?) endif() User thinks: okay, if I set A=ON I will have B equal to Hello A. What user really have: 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 one of the reason why they said CMake is not a good script language. Just like CMake before CMP0054: user see `if(a STREQUAL b)` and think okay, 'a' is not equal to 'b' so this condition is always false... nope! Ruslo -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 could be done without
confusing users and making scripting harder.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
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 CMAKE_BUILD_TYPE AND (NOT ${CMAKE_BUILD_TYPE} STREQUAL None))
SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING Choose the
type of build, options are: Debug Release RelWithDebInfo)
ELSE()
SET(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING Choose the type
of build, options are: Debug Release RelWithDebInfo FORCE)
ENDIF()
Can someone give me the proper one-line way to set a default for
CMAKE_BUILD_TYPE, or is this an authentic problem?
This seems to work for me:
set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo)
Wow, never heard of that variable, thanks
Is that documented?
Can you just slam _INIT on the end of any cache variable to give it a
default value, or is that a special case?
- Dan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 users hit
such kind of situations that's one of the reason why they said CMake is
not a good script language. Just like CMake before CMP0054: user see
`if(a STREQUAL b)` and think okay, 'a' is not equal to 'b' so this
condition is always false... nope!
OK, it is a bit confusing. One solution would be to treat the cache
variables with some sort of separate look up. Basically put all cache
stuff into its own namespace.
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.
-Bill
I'm not sure I understand this solution. If you mean that user should
not mix cache/non-cache variables with the same name, I guess yes (good
idea for policy by the way). But it will not fix that kind of issues:
cmake_minimum_required(VERSION 3.0)
project(Foo)
set(A OFF CACHE BOOL This is A)
if(A) # Yes, A is cache variable
set(B Hello A CACHE STRING Do we use A?)
else()
set(B There is no A CACHE STRING Do we use A?)
endif()
result will be quite the same. The fundamental reason of this is that
every cache (as a general term) have a context where it can be used, and
if context changing we can't reuse same cached value. For variable B
this context is value of A:
cmake -H. -B_builds # use default value OFF
save to cache: B=There is no A context: A=OFF
cmake -H. -B_builds -DA=ON
load from cache: B=There is no A context: A=OFF # that's the
problem, context is not the same, but we still using variable from cache
For more complex example let's use CMAKE_PREFIX_PATH and find_package:
find_package(Foo CONFIG REQUIRED)
message(Foo_DIR: ${Foo_DIR})
rm -rf _builds
cmake -H. -B_builds -DCMAKE_PREFIX_PATH=location-A
Foo_DIR: location-A
cmake -H. -B_builds -DCMAKE_PREFIX_PATH=location-B
Foo_DIR: location-A # Still location-A!
rm -rf _builds
cmake -H. -B_builds -DCMAKE_PREFIX_PATH=location-B
Foo_DIR: location-B
You can said that it's kind of obvious that you must clear the cache if
you're changing such critical variables like CMAKE_PREFIX_PATH but in
this case think about tools that want to do such things automatically
and efficiently. There is no big difference between A and
CMAKE_PREFIX_PATH, in both cases it's just a CMake variable.
Ruslan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
It doesn't look like it's documented, at least in the command line
--help-variable.
It's a special case, which I think works for a lot of the build flag related
cache variables (though for a lot of the others, you probably need to put
values in e.g. a c_flag_overrides.cmake included by setting
CMAKE_USER_MAKE_RULES_OVERRIDE so they can be dependent on detected
platform/compiler settings).
--
Daniel Schepler
From: daniel.r.ke...@gmail.com [daniel.r.ke...@gmail.com] on behalf of Dan
Kegel [d...@kegel.com]
Sent: Friday, July 31, 2015 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
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))
SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING Choose the
type of build, options are: Debug Release RelWithDebInfo)
ELSE()
SET(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING Choose the type
of build, options are: Debug Release RelWithDebInfo FORCE)
ENDIF()
Can someone give me the proper one-line way to set a default for
CMAKE_BUILD_TYPE, or is this an authentic problem?
This seems to work for me:
set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo)
Wow, never heard of that variable, thanks
Is that documented?
Can you just slam _INIT on the end of any cache variable to give it a
default value, or is that a special case?
- Dan
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 at the Visual C++ team who are looking for a way to hook CMake into the IDE. So, if all goes well it might even happen. TortoiseCMake :) -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
@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 SHOULD EXIST and be well defined. Hooking all the generators straight into the script interpreter is not good. The only reason I intially chose XML and XSD is because they are readily available in just about any language. (Take the C++ codegen lib for instance) The big difference is that XSD is a widely adopted recommendation. Every lib supports it. The moment JSON can provide a schema that is as widely adopted as XSD, I have no objection against JSON. I read through http://www.w3schools.com/Schema/default.asp in a matter of a few hours and it as simple as things can get. But spawning a JSON schema for this project alone would feel like being back at square 1. Even if nothings becomes of this idea, if CMake could manifest such a thing (like LLVM is for… just about everything C++ related), it would both distill the internals into something easier to comprehend, and at least significantly increase interoperability with IDEs and it’s own generators. (Deferred generation would be a welcome side-effect. The generators would only be invoked once the IR is complete. Whether the generator make use of the global info or spawn build invocations and targets on their first encounter is up to the generator to decide.) @Dan: I don’t quite understand resistance toward MS tech. Windows resides on +80% of PCs in the world, CMake already has VS and NMake generators… if there existed multiple input languages, I do not understand why one of them couldn’t be a native Windows script language. @Eric: Thank you for the extensive and thorough answer. I have not taken a look at Gyp, but will surely do. As for conditionals and complex scenarios. If the people who encountered such barriers could elaborate a little on what their experiences were, maybe design could take such cases into consideration from day one. 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 at the Visual C++ team who are looking for a way to hook CMake into the IDE. So, if all goes well it might even happen.-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 like that idea. Many different languages would make supporting (as in helping someone with his project) and understanding arbitrary CMake projects much harder. I would certainly be for adding a single additional script language though. I am personally still rooting for Lua. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 helping someone with his project) and understanding arbitrary CMake projects much harder. +1 Also, adding XML of any sort to CMake would instantly taint it with ugly-stink. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 their project/needs/skills. I don't like that idea. Many different languages would make supporting (as in helping someone with his project) and understanding arbitrary CMake projects much harder. +1 Also, adding XML of any sort to CMake would instantly taint it with ugly-stink. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 general case. They probably work well as a way to feed parameters to a single build backend, but not so good as a way to handle multiple backends. gyp is one attempt to do this, and it worked, but it's painful to use and requires deep understanding of the gyp model. So, +1 for the idea of adding a better language on the side of cmake, -1 for adding multiple languages (especially anything from Microsoft), and -1 for going fully stateless. 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. - Dan -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 stores things it finds during the configure step. If you did not have it you would have to rediscover everything for every run on a build tree, and have no place to store user selections in the GUI. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 the hardest selling point in my experience, even when you convince them that CMake can do all the cross-platform stuff. (I’m seeing more competition from Gyp these days, but in my limited personal experience, people still have not been able to port highly complex projects to as many target platforms with Gyp, whereas CMake could handle them (and the perceived gains of Gyp disappeared in these complex scenarios)). - Along those lines, part of the problem we seemed to hit was that pure declarative build instructions didn’t hold up well in the complex case. I haven’t done much with Gyp in this manner, but those around me that were trying seemed to hit the wall pretty fast in this. But I have used Ant, and that was a terrible experience for anything that required conditionals. - I would definitely like to see better interoperability with IDEs and tools. I would personally love a simple cross-platform gui project manager that basically allowed you to create targets, add/remove files to be compiled to a target, and set specific compile/link flags on a per-target or per-file basis, sort of like you can do in most IDEs (but if you tried using CMake, your changes get clobbered in the next regeneration…though even better would be able to do this directly in the native IDEs). - I am little concerned about encouraging people to add on any arbitrary language. There are two different problems that this could potentially cause: (1) CMake bloat, (2) Dependency hell - CMake currently can bootstrap itself with just a C++ compiler. That is a good thing. I recently had to get CMake up on a Raspberry Pi. I was fortunate that CMake had few dependencies and was relatively small. (Not counting Qt which was an unmitigated disaster.) - Building other projects using CMake can be painful depending on their dependency chain. While this is not technically CMake’s responsibility, encouraging users to use non-canonical tools can make things a nightmare. CMake has been pretty good about providing fundamental mechanisms you need that work on all platforms. But if users are encouraged to say, “I’ll just use Perl+CPAN or Ruby with these gems”, instead of the standard CMake mechanisms, things get awful quickly. (I finally just reproduced a build of JavaScriptCore for Windows after over a year of trying…it has dependencies on Perl, Python, Ruby, and a bunch of other things I can’t remember, all of which are a terrible pain to get working on Windows.) - In that same line of thought, the reason Lua was a good candidate is because it its tiny which avoids adding bloat, it is pure ANSI C, which means it compiles everywhere CMake already compiles, and it was designed to be an embedded scripting language doing the exact type of things that the current CMake language is asked to do. (Dr. Ken Martin said they were impressed with Lua and would have used it if they had known about it originally.) (By the way, if you haven,t already, I encourage you to read through the old Lua threads circa 2008.) - Incidentally, the Lua table is pretty much the same concept/pre-cursor to JSON in JavaScript. Lua lends it self to both data driven formats as well as custom DSLs pretty well. If Lua were part of the core, you could build a the data-oriented format files without any additional dependencies. - I don’t think the IR will help anything related to the work of adding new languages like Swift. The hard part there is not really the CMake language as much as understanding the overall system design/architecture. No matter what language you pick, that part will always be hard. - Mostly, I’m concerned that this project is too big and ambitious in scope to see completion unless you have funding and a team to drive it. The Lua attempt is a failure, but not for technical reasons. It was a manpower problem. Dr. Ken Martin proved the concept could work in something like 13 hours. But at the time Kitware said they weren’t going to go down that road, so anybody still interested in it was left to make it happen ourselves. We gave it a shot, but none of us really had the time to commit to finish the task, which is much smaller than the one you are proposing. (Granted, we wasted a lot of time trying to bridge CVS (which CMake was still using at the time) with DVCS, so you at least won’t have to worry about constant merge-hell.) -Eric -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake
Re: [CMake] [cmake-developers] CMake IR
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 could gain even greater momentum (not by ditching, but) by offering alternate input languages with entities (classes, functions, macros, etc.) that feel natural in the given context. Well, the cmake language is not really pretty, but in my experience it is usually good enough. Having a somewhat better language like e.g. Lua may be a good thing. There is actually an advantage in not thaving a full-featured scripting language: users are less tempted to turn the build scripts into actual programs containing logic and doing a lot of stuff. I have seen that happen with scons builds... as developer you had to understand two programs: the actual software, and the build program. There were already experiments with Lua and also with Javascript for cmake, but they didn't succeed so far. Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 cmake scripts, but that's not a battle I'd like to wage. No, it is how CMake stores things it finds during the configure step. If you did not have it you would have to rediscover everything for every run on a build tree, and have no place to store user selections in the GUI. 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. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 support which CMake features. 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. When trying to get a team to adopt CMake, learning this new language is a barrier for entry. Doing a trade study on build tools made SCons looks pretty good because it is in python, but ultimately we decided on CMake because I used it before. Geoffrey Viola SOFTWARE ENGINEER asirobots.com This message contains confidential information and is intended only for the recipient. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately if you have received this e-mail by mistake and delete this e-mail from your system. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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 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 stores things it finds during the configure step. If you did not have it you would have to rediscover everything for every run on a build tree, and have no place to store user selections in the GUI. 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. Which don't you believe? The part where if you don't have a cache then you have to rediscover everything? Simply delete the CMakeCache.txt file and rerun CMake. You will rediscover everything. If you do not have some sort of state file then exactly how would one store their selections? Since you are comfortable on the command line I'll assume you love typing: cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/usr/foo -DCXX_COMPILE_FLAGS=All -DKEEP_GOING_WITH_EVEN_MORE_ARGUMENTS -G Ninja ../YourProject. For shorter invocations this isn't so bad to type. We have our project down to a single argument, but we preload from, wait for it, a cache file. But what about those folks who are simply NOT comfortable on the command line and always use the GUI? If CMake _never_ had a GUI then your argument might have some merit. If your next thought is something like .. Well just write an alias in your .bashrc so you do not have to type it out each time.. then didn't you just basically create a cache file? And if you vote for just rediscover everything, every time then you have never run CMake on a larger project on a Windows machine with Visual Studio. Now _that_ is slow. I think the history of the design implementations kind of shows that a Cache is more helpful than hurtful. Plus when Project developers decide to hard code their own version of dependent libraries and give you no way of over riding those settings OTHER than hand editing the cache file, then be thankful you have the cache file there. Just my 2 cents. Mike Jackson -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] CMake IR
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, find_library, find_program result is stored there as well. If you did this each time, it would be not only slow to re-run a build, but it might come up with different answers each time. If it went it would complicate your life even more. In what way do you think it is causing you trouble? Also, CMake needs to be able to auto-rerun when its input changes and this is how the command line -D options are saved along with all the other system introspection results. -Bill -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
