git: Revamp alt compiler handling for clang 3.9.1 import.

Rimvydas Jasinskas zrj at crater.dragonflybsd.org
Tue Dec 6 22:18:58 PST 2016


commit 8d7da4247e43eb2bbe924d08f6a40ef80d742515
Author: zrj <rimvydas.jasinskas at gmail.com>
Date:   Mon Dec 5 20:11:24 2016 +0200

    Revamp alt compiler handling for clang 3.9.1 import.
    
    Many users are still constantly asking weather llvm/clang compiler could be
    added into a base as an alternative to current used ones (gcc50 and gcc47).
    There are few issues in doing that:
     * It is very hard to keep both compiler flavors in harmony while one or the
       other is being updated. There were always two base compilers in base system
       in DragonFly and common practice still is to replace previous alternative
       compiler with an updated version, performing tests and then flip them up.
     * With clang introduction, this scheme would break badly due to both using
       slightly different c++ capabilities, flags support (WARNS mechanism), etc.
     * Different incompatible libraries libLLVM + libc++ vs libstdc++, also clang
       requiring a lot of effort to rewrite cmake logic into Makefiles for make(1).
     * SBU costs, gcc47 only has ~4min buildtime overhead at -j5 level(i7 laptop)
       while even clang38 tests has shown two-fold increase in buildworld time.
     * How DPorts infrastructure would handle both flavors? License roadmap?
    
    So to make compromise it was chosen to provide a way for users and developers
    to select the alternative compiler they like while keeping all groups happy,
    ones continuing to enjoy the very fast world rebuilds and others having a way
    to further develop and integrate clang into the infrastructure. Since DragonFly
    is currently x86_64 only, we might as well experiment more with compilers.
    
    This changeset adds some flexibility when it comes to handling base system
    compilers. Even if it would be decided that clang does not fit very well in
    DragonFly base system (due to complexities, updating/patching problems and
    compilation times), we at least will have a very clean way for adding,
    testing and finally making base default upcoming gcc70 and later. All of this
    would be possible without disturbing both primary and alternative default
    compilers, while developers and users will be testing both base and dports.
    Also as a bonus we will be able to add compilers like pcc and scc that have
    no native c++ frontend support too while reusing default compiler parts.
    For now I am keeping this expansion undocumented and candidate for a revert.
    
    While there mark few places for further work to reduce amount of ORDER: for
    faster/better parallelism in btools/ctools bootstrapping stages.
    
    Bootstrap is still fine from DragonFly 4.0.6-RELEASE.

Summary of changes:
 Makefile.inc1              | 53 +++++++++++++++++++++++++++++++++++++++-------
 etc/defaults/make.conf     |  2 +-
 gnu/lib/Makefile           |  2 ++
 gnu/usr.bin/Makefile       | 10 +++++----
 share/man/man5/make.conf.5 |  2 +-
 share/mk/sys.mk            | 11 +++++++++-
 6 files changed, 65 insertions(+), 15 deletions(-)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/8d7da4247e43eb2bbe924d08f6a40ef80d742515


-- 
DragonFly BSD source repository


More information about the Commits mailing list