to be used for generated headers which are not delivered to solver.

First a color is set , then another color is set .We finally check again by issuing an undo and checking if the prev color is now set

this boost::ptr_vector idea is seriously broken

Especially given it's not namespaced (const is automatically static).

String literals should be reasonably short, and if memory is so low
that they trigger allocation failure, something else would would
trip over very soon anyway.

Boost is reportedly 'expertly designed C++ library', so why do I
find the idea of a container containing pointers but exposing them
by value to be rather retarded? I don't know why exactly this
crashes, but I expect std::sort() either either does unwanted
copies that break things or the copies slice off inherited classes.

Having done this on a temporary basis a couple of times before,
it'd be good to avoid having to do the instrumentation again.

...the same way cpp_uno/mingw_intel was already adapted.

...for reasons that are yet unclear to me.

Apparently the order in makefile.mk matters. Without this higher,
acceptor.uno.dll does not get built.

shasum is only needed to detect a bug in some version of gnumkae
do not burden platform with a non-impacted gnu make with
that requirement

Hmm, /usr/bin/shasum is a Perl implementation (!), should we use
"openssl sha1" instead?