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.