Re: [cmake-developers] CMake IR

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Nils Gladitz-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Dan Kegel
>>     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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

CMake mailing list
json is SOOO much sexier than XML..... ;-)

On Thu, Jul 30, 2015 at 10:10 AM, Dan Kegel <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Dan Kegel
On Thu, Jul 30, 2015 at 9:30 AM, David Cole <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

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, 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Geoffrey Viola
In reply to this post by Nils Gladitz-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Dan Kegel
In reply to this post by Bill Hoffman


Am 30.07.2015 10:15 vorm. schrieb "Bill Hoffman" <[hidden email]>:
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Michael Jackson

On Jul 30, 2015, at 11:56 AM, Dan Kegel <[hidden email]> wrote:


Am 30.07.2015 10:15 vorm. schrieb "Bill Hoffman" <[hidden email]>:
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Bill Hoffman
In reply to this post by Dan Kegel
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Alexander Neundorf-3
In reply to this post by Nils Gladitz-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Eric Wing
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 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

CMake mailing list
@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 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

J Decker

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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Dan Kegel
In reply to this post by Eric Wing
On Fri, Jul 31, 2015 at 2:05 AM, Nagy-Egri Máté Ferenc <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

CMake mailing list
In reply to this post by Bill Hoffman
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Dan Kegel
On Fri, Jul 31, 2015 at 11:33 AM, Ruslan Baratov
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Bill Hoffman
In reply to this post by CMake mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Daniel Schepler
In reply to this post by Dan Kegel
This seems to work for me:
set(CMAKE_BUILD_TYPE_INIT RelWithDebInfo)
--
Daniel Schepler
________________________________________
From: CMake [[hidden email]] on behalf of Dan Kegel [[hidden email]]
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
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Dan Kegel
In reply to this post by Bill Hoffman
On Fri, Jul 31, 2015 at 11:43 AM, Bill Hoffman <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] CMake IR

Dan Kegel
In reply to this post by Daniel Schepler
On Fri, Jul 31, 2015 at 11:44 AM, Daniel Schepler
<[hidden email]> 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
12