Re: [boost] CMake - one more time

Subject: Re: [boost] CMake - one more time
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-04-26 14:02:09

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.