So create a proper configuration with these flags instead of hacking them in using command line or system environment. That way they'll be cleanly visible in the build file instead of being tucked-in in a some obscure driver script.So... I pointed out that scons requires understanding and hacking every single build script rather than just putting configuration state in one centralized place (be that a site-config file, as, autoconf, or a wrapper that runs the tool, as cmake)... and you suggest that I should fix this by... understanding and hacking every build script!
I suspect that you don't understand what I'm driving at. A build system which requires distributors to hack every build script in order to make simple adjustments to flags and paths will never be popular among distributors, and packages that use it will forever be discriminated against and make packagers and builders despair when they meet them.
Portable? They don't work with MSVC which is probably the most popular C++ compiler.Now I know you're just trying to win regardless of logic. POSIX programs are very rarely portable to MSVC: I can count the number of programs on my Linux system that can also be built with MSVC on the fingers of two hands (and if I rule out SDL and its subsidiary packages, that's one hand). Generally such packages need radical internal surgery to make them work on Windows at all, and working without an abstraction layer such as Cygwin is even harder.
So, sorry, portability to MSVC is rarely worth considering when looking at Unix build systems.
Even for such programs, msys provides a platform specifically intended to allow configure scripts to run. (It's not heavyweight.)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds