On 4/26/16 10:33 AM, Paul Fultz II wrote:
On Tuesday, April 26, 2016 at 11:03:26 AM UTC-5, Robert Ramey wrote:
Ok, I tried out the GUI to see for myself. Its as horrible as you are describing.
LOL - I don't mean to make the case that it's horrible - I was just trying to describe how it works. I gather that my description more or less refected your own experience.
You can also set variables, and this part is not clear in the gui. For example, if I want to build with warnings, from the command line I run `cmake .. -DCMAKE_CXX_FLAGS='-Wall -Werror'` and the project will be built with warning flags. To do the same with the GUI, you must first use the 'Add Entry'
Hmmm - this stuff I put in the CMakeList.txt itself since it's not something I want to change. I use add_definition so that it's compiler agnostic.
4) then use add_library(library_name ${LINK_TYPE} ...)
Yes, but cmake provides `BUILD_SHARED_LIBS` to do the same thing, and it even gives a recommendation in the documentation on how to configure it. It says "This variable is often added to projects as an option()".
LOL - I looked through that - but then I couldn't really figure out what "option" was really supposed to do. Also it was include how BUILD_SHARED_LIBS would be set If I didn't add_library(STATIC or SHARED...) It seems that the variable could be set in a number of different places (worse, in any CMakeLists.txt file which I might not know about). Then the question arose as to whether the STATIC / SHARED in the add_library was a string variable or a key word. Basically it's the old "global variable" distributed source problem. It's not that it can't be made to work it's just that it's opaque, fragile, and time consuming. My method was simple and bullet proof because it isn't global doesn't depend on anything it can't see. But I wasn't thinking of "theoretical" software design considerations. I was just making the damn think work reliably in the most expedient way possible.
I'm aware you're going to see this as another example of "fighting the system" - and you're right. It's just that sometimes you have to fight to make the system work.
But how does `option(BUILD_SHARED_LIBS "Build shared")` not work?
whoops see above. I don't know that it doesn't work - I couldn't figure out what it's really supposed to do.
The final result is a system which works pretty well. I don't have to remember anything. In fact it works much, much better than actually editing the IDE. To add new source file, I just tweak the CMakeLists.txt and regenerate the IDE.
I would say the exact opposite. The thing I like about cmake is that I can build my project with MSVC without ever needing to touch the IDE.
LOL - OK you you don't like using an IDE - fair enough. I'm sure you've got a good argument why using an IDE is something to avoid. Good luck on convincing the world that you're right about.
This could be seen as an endorsement of CMake. It's not - the above description doesn't really capture the fact that there is a lot of experimentation and trial and error involved. It's like training an ant to train a flee. One can just read the docs, know what to do, write an unambiguous script and expect it to work. All we can really do is "fix it up" by creating another level of abstraction on top. Unfortunately, Most of time, these higher level abstractions are made with the same type of thinking which leads to the original problem.
Usually when the abstraction level goes up, its because its managing more complexity.
That's certainly the intention. Whether that in fact happens or not depends upon the how the abstraction is designed and implemented. Abstraction alone is not sufficient to improve and interface. All libraries are and attempt at abstraction. How many times have you tried to use a library and found that it was so confusing that rather than making the task at hand easier, it makes it harder. It's a common occurence. It's not that the library author didn't have good intentions, it's not that designing a higher level abstraction is not the right idea, it's that it's just hard to design something simple and unambiguous and decoupled from something else.
Ambiguously defined rules, functions with side-effects, etc. etc.
I don't know what you are talking about. There is no ambiguously defined rules.
LOL - see my rant about option() above. it's not clear where one should put it, how it interacts with option placed somewhere else, whether the options are string variables or some sort of instrinsic, what is the default, how it interacts with someone placing the option on the command line. This is just a tiny simple example and a very simple one compared to others. One could supply pages and pages and pages of such examples - but thankfully one is sufficient. Robert Ramey FWIW - it's not just CMake, it's the whole software developement process and tools. We're swamped in tools which don't have enough formality to force us to be correct. We get stuff which we can write in 30 seconds and it usually works. But more often than not, it fails silently sometime later. The ones I know about are PHP, perl, javascript, basic, excel. Those are only the ones I know about of the top of my head. The world is grinding to a halt on this stuff.