Build2 is an open source, cross-platform toolchain for building and packaging C++ code

Overview
This package contains the build2 build system.

build2 is an open source, cross-platform toolchain for building and packaging
C++ code. Its aim is a modern build system and dependency manager for the C++
language that provide a consistent, out of the box interface across multiple
platforms and compilers. For more information see:

https://build2.org/

See the NEWS file for the user-visible changes from the previous release.

See the LICENSE file for the distribution conditions.

See the INSTALL file for the prerequisites and installation instructions.

See the doc/ directory for documentation.

Send questions, bug reports, or any other feedback to the [email protected]
mailing list. You can post without subscribing. See https://lists.build2.org
for searchable archives, posting guidelines, etc.
Comments
  • How configurable is project structure?

    How configurable is project structure?

    First of all, thanks a lot for tackling all of modern C++ building/packaging issues and for tremendous effort put into this project!

    This is the first build system since Make that gave me hope for a better tomorrow. However, I'm questioning some decisions and I'd like to discuss/clarify them or find out how to achieve something closest to my desired project setup.

    After running bdep new -l c++,cpp -t lib,split libproject, the project looks like this:

    > tree -a -I .git* libproject
    libproject/
    ├── .bdep
    │   └── bdep.sqlite3
    ├── build
    │   ├── bootstrap.build
    │   ├── export.build
    │   └── root.build
    ├── buildfile
    ├── include
    │   └── libproject
    │       ├── buildfile
    │       ├── export.hpp
    │       ├── project.hpp
    │       └── version.hpp.in
    ├── manifest
    ├── README.md
    ├── repositories.manifest
    ├── src
    │   └── libproject
    │       ├── buildfile
    │       └── project.cpp
    └── tests
        ├── basics
        │   ├── buildfile
        │   └── driver.cpp
        ├── build
        │   ├── bootstrap.build
        │   └── root.build
        └── buildfile
    

    There is quite a lot of clutter for this simplest project that I find quite unappealing.

    1. build directory is traditionally used for the output of the build systems and it's quite misleading and unexpected to find it to be a config directory for build2. In my opinion, much better name for it would be build_config, build2_config or something along the line. What do you think?

    2. I have read in the documentaiton that creating build configurations/output anywhere inside of project is forbidden, but I still don't understand why? It's one thing to forbid build configurations to be mixed with code, but I don't see any reason nor limitation not to have build/{gcc,clang++,...} configurations/output inside of self-contained project.

    3. There are just too many "config" files scattered across the project, does it has to be that way? Can't we group everything except buildfiles in (hidden) directorires to reduce the clutter?

    4. Public include directory contains 3 generated headers just for the build system. Do they have to be there for the installation (probably only for Windows)? If yes, can we name them differently to distinguish them and ignore for non-Windows platforms? If no, I would prefer to have configuration inside of some buildfile for that and expect build2 to provide them for Windows builds.

    5. I get that build2's targets are directories and that's probably why each directory that has anything user-created also has buildfile and even additional configuration for it. I assume this is done to give full control to the users who want for each directory to do different kind of magic and that's fine. However, I'm wondering if these things could be done from top-level configuration in one place rather than having build files all over the project? Can this be achieved by something like Make's target-specific variables (and in case of build2, target-specific configuration)?

    For the reference, I would prefer following project structure:

    ideal_libproject
    ├── README.md
    ├── include                                  # Public module interfaces ready for installation (with minimal clearly distinguished clutter).
    │   └── ideal_libproject
    │       ├── ideal_libproject.mpp
    │       └── ...
    ├── src                                      # Source code for library and its tests.
    │   ├── ideal_libproject
    │   │   ├── ideal_libproject.cpp
    │   │   └── ...
    │   └── tests                                # Tests should probably follow same project structure if we want incremental testing.
    │       ├── unit
    │       │   ├── ideal_libproject_test.cpp
    │       │   └── ...
    │       └── ...
    ├── buildfile                                # Top-level configuration that describes rules for project subdirectories as well.
    ├── build2_config                            # Whole project/repository configuration.
    │   ├── .hidden_build2_stuff                 # Hidden part of build2 stuff that shouldn't be touched.
    │   │   └── ...
    │   └── ...
    └── build                                    # Build configurations for the project.
        ├── gcc
        │   └── ...                              # Should not contain "recursive" `build` and optionally top-level `ideal_libproject` directories.
        └── ...
    

    Sorry for dumping all the questions/ideas like this! It would be nice if you can help me understand what is reasonable (and already configurable) to expect and what isn't (and why). Also, I don't mind helping out with the implementation.

    opened by Iskustvo 16
  • Support for simple projects pulling in other projects

    Support for simple projects pulling in other projects

    I have a project with three packages:

    [~/src/atomic_queue] $ tree
    .
    ├── benchmark
    │   ├── benchmark
    │   │   ├── benchmark.cxx
    │   │   ├── buildfile
    │   │   └── moodycamel.hxx
    │   ├── build
    │   │   ├── bootstrap
    │   │   │   └── out-root.build
    │   │   ├── bootstrap.build
    │   │   └── root.build
    │   ├── buildfile
    │   └── manifest
    ├── libatomic_queue
    │   ├── build
    │   │   ├── bootstrap
    │   │   │   └── out-root.build
    │   │   ├── bootstrap.build
    │   │   ├── export.build
    │   │   └── root.build
    │   ├── buildfile
    │   ├── libatomic_queue
    │   │   ├── atomic_queue.cxx
    │   │   ├── atomic_queue.hxx
    │   │   ├── atomic_queue_mutex.hxx
    │   │   ├── barrier.hxx
    │   │   ├── buildfile
    │   │   ├── cpu_base_frequency.cxx
    │   │   ├── cpu_base_frequency.hxx
    │   │   ├── defs.hxx
    │   │   ├── export.hxx
    │   │   ├── spinlock.hxx
    │   │   └── version.hxx.in
    │   └── manifest
    ├── LICENSE
    ├── Makefile
    ├── packages.manifest
    ├── README.md
    ├── repositories.manifest
    ├── test
    │   ├── build
    │   │   ├── bootstrap
    │   │   │   └── out-root.build
    │   │   ├── bootstrap.build
    │   │   └── root.build
    │   ├── buildfile
    │   ├── manifest
    │   └── test
    │       ├── buildfile
    │       └── test.cxx
    └── buildfile
    

    I would like b to build all packages when invoked from the top level project directory. When I add a buildfile to the top level directory with the following content:

    ./: {*/ -build/} doc{README.md LICENSE}
    

    And run b it dumps core:

    [~/src/atomic_queue] $ b --version
    build2 0.11.0
    libbutl 0.11.0
    host x86_64-linux-gnu
    Copyright (c) 2014-2019 Code Synthesis Ltd
    This is free software released under the MIT license.
    
    [~/src/atomic_queue] $ cat buildfile 
    ./: {*/ -build/} doc{README.md LICENSE}
    
    [~/src/atomic_queue] $ b
    Segmentation fault (core dumped)
    
    [~/src/atomic_queue] $ mv {,x}buildfile
    [~/src/atomic_queue] $ b
    error: no buildfile in ./
      info: consider explicitly specifying its src_base
    
    [~/src/atomic_queue] $ cd ../atomic_queue-gcc/
    [~/src/atomic_queue-gcc] $ b
    mkdir libatomic_queue/fsdir{libatomic_queue/}
    mkdir test/fsdir{test/}
    mkdir benchmark/fsdir{benchmark/}
    version.in ../atomic_queue/libatomic_queue/libatomic_queue/version.hxx.in
    c++ ../atomic_queue/libatomic_queue/libatomic_queue/cxx{atomic_queue}@libatomic_queue/libatomic_queue/
    c++ ../atomic_queue/libatomic_queue/libatomic_queue/cxx{atomic_queue}@libatomic_queue/libatomic_queue/
    c++ ../atomic_queue/libatomic_queue/libatomic_queue/cxx{cpu_base_frequency}@libatomic_queue/libatomic_queue/
    c++ ../atomic_queue/libatomic_queue/libatomic_queue/cxx{cpu_base_frequency}@libatomic_queue/libatomic_queue/
    c++ ../atomic_queue/benchmark/benchmark/cxx{benchmark}@benchmark/benchmark/
    c++ ../atomic_queue/test/test/cxx{test}@test/test/
    ar libatomic_queue/libatomic_queue/liba{atomic_queue}
    ld libatomic_queue/libatomic_queue/libs{atomic_queue}
    ld test/test/exe{test}
    ld benchmark/benchmark/exe{benchmark}
    

    Stacktrace:

    (gdb) r -V
    Starting program: /usr/local/bin/b 
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    [New Thread 0x7ffff6803700 (LWP 12432)]
    [New Thread 0x7ffff5fb2700 (LWP 12451)]
    [New Thread 0x7ffff5761700 (LWP 12452)]
    
    Thread 2 "b" received signal SIGSEGV, Segmentation fault.
    [Switching to Thread 0x7ffff6803700 (LWP 12432)]
    0x000055555587e944 in butl::project_name const& build2::cast<butl::project_name>(build2::value const&) ()
    (gdb) bt
    #0  0x000055555587e944 in butl::project_name const& build2::cast<butl::project_name>(build2::value const&) ()
    #1  0x000055555587c78b in build2::import(build2::scope&, build2::name, build2::location const&) ()
    #2  0x00005555557c3c47 in build2::parser::parse_import(build2::token&, build2::token_type&) ()
    #3  0x00005555557cd425 in build2::parser::parse_clause(build2::token&, build2::token_type&, bool) ()
    #4  0x00005555557ce959 in build2::parser::parse_buildfile(std::istream&, butl::basic_path<char, butl::any_path_kind<char> > const&, build2::scope&, build2::scope&) ()
    #5  0x00005555558769cb in build2::source(build2::scope&, build2::scope&, butl::basic_path<char, butl::any_path_kind<char> > const&, bool) ()
    #6  0x0000555555876d90 in build2::source_once(build2::scope&, build2::scope&, butl::basic_path<char, butl::any_path_kind<char> > const&, build2::scope&) ()
    #7  0x00005555556f28ff in build2::dir_search(build2::target const&, build2::prerequisite_key const&) ()
    #8  0x0000555555839a5d in build2::search(build2::target const&, build2::prerequisite_key const&) ()
    #9  0x000055555565db9b in build2::search(build2::target const&, build2::prerequisite const&) ()
    #10 0x000055555583f83b in build2::match_prerequisites(build2::action, build2::target&, std::function<build2::prerequisite_target (build2::action, build2::target const&, build2::prerequisite const&, build2::include_type)> const&, build2::scope const*) ()
    #11 0x0000555555845582 in build2::alias_rule::apply(build2::action, build2::target&) const ()
    #12 0x000055555583a20d in build2::apply_impl(build2::action, build2::target&, std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, std::reference_wrapper<build2::rule const> > const&) ()
    #13 0x000055555583b8a5 in build2::match_impl(build2::target_lock&, bool, bool) ()
    #14 0x000055555583bb28 in build2::match(build2::action, build2::target const&, unsigned long, std::atomic<unsigned long>*, bool)::{lambda(build2::diag_frame const*, build2::target_lock const*, build2::target&, unsigned long)#1}::operator()(build2::diag_frame const*, build2::target_lock const*, build2::target&, unsigned long) const ()
    #15 0x000055555583bc33 in void build2::scheduler::task_thunk<build2::match(build2::action, build2::target const&, unsigned long, std::atomic<unsigned long>*, bool)::{lambda(build2::diag_frame const*, build2::target_lock const*, build2::target&, unsigned long)#1}, build2::diag_frame const*&, build2::target_lock const*&, std::reference_wrapper<build2::target>, unsigned long&>(build2::scheduler&, std::unique_lock<std::mutex>&, void*) ()
    #16 0x00005555557eece1 in build2::scheduler::helper(void*) ()
    #17 0x00007ffff773f6db in start_thread (arg=0x7ffff6803700) at pthread_create.c:463
    #18 0x00007ffff6ec788f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
    
    (gdb) info registers
    rax            0x7ffff67fc5a0	140737328956832
    rbx            0x7ffff67fcf30	140737328959280
    rcx            0x0	0
    rdx            0x0	0
    rsi            0x5f626173	1600282995
    rdi            0x0	0
    rbp            0x7ffff67ff0e0	0x7ffff67ff0e0
    rsp            0x7ffff67fc3d0	0x7ffff67fc3d0
    r8             0x0	0
    r9             0x555555b622a0	93824998580896
    r10            0x7ffff00008d0	140737219922128
    r11            0x5555558c6bd4	93824995847124
    r12            0x555555b636c8	93824998586056
    r13            0x555555b636d8	93824998586072
    r14            0x7ffff67fc5a0	140737328956832
    r15            0x7ffff67fcd10	140737328958736
    rip            0x55555587e944	0x55555587e944 <butl::project_name const& build2::cast<butl::project_name>(build2::value const&)+4>
    eflags         0x10202	[ IF RF ]
    cs             0x33	51
    ss             0x2b	43
    ds             0x0	0
    es             0x0	0
    fs             0x0	0
    gs             0x0	0
    (gdb) disassemble
    Dump of assembler code for function _ZN6build24castIN4butl12project_nameEEERKT_RKNS_5valueE:
       0x000055555587e940 <+0>:	sub    $0x8,%rsp
    => 0x000055555587e944 <+4>:	cmpb   $0x0,0x8(%rdi)
       0x000055555587e948 <+8>:	jne    0x55555587e9b9 <_ZN6build24castIN4butl12project_nameEEERKT_RKNS_5valueE+121>
       0x000055555587e94a <+10>:	mov    (%rdi),%rdx
       0x000055555587e94d <+13>:	test   %rdx,%rdx
       0x000055555587e950 <+16>:	je     0x55555587e96e <_ZN6build24castIN4butl12project_nameEEERKT_RKNS_5valueE+46>
       0x000055555587e952 <+18>:	lea    0x2b65e7(%rip),%rcx        # 0x555555b34f40 <_ZN6build212value_traitsIN4butl12project_nameEE10value_typeE>
       0x000055555587e959 <+25>:	cmp    %rcx,%rdx
       0x000055555587e95c <+28>:	jne    0x55555587e965 <_ZN6build24castIN4butl12project_nameEEERKT_RKNS_5valueE+37>
       0x000055555587e95e <+30>:	jmp    0x55555587e990 <_ZN6build24castIN4butl12project_nameEEERKT_RKNS_5valueE+80>
       0x000055555587e960 <+32>:	cmp    %rcx,%rdx
       0x000055555587e963 <+35>:	je     0x55555587e990 <_ZN6build24castIN4butl12project_nameEEERKT_RKNS_5valueE+80>
       0x000055555587e965 <+37>:	mov    0x10(%rdx),%rdx
       0x000055555587e969 <+41>:	test   %rdx,%rdx
       0x000055555587e96c <+44>:	jne    0x55555587e960 <_ZN6build24castIN4butl12project_nameEEERKT_RKNS_5valueE+32>
       0x000055555587e96e <+46>:	lea    0x4a36b(%rip),%rcx        # 0x5555558c8ce0 <_ZZN6build24castIN4butl12project_nameEEERKT_RKNS_5valueEE19__PRETTY_FUNCTION__>
       0x000055555587e975 <+53>:	mov    $0x9d,%edx
       0x000055555587e97a <+58>:	lea    0x20b4f(%rip),%rsi        # 0x55555589f4d0
       0x000055555587e981 <+65>:	lea    0x20c2f(%rip),%rdi        # 0x55555589f5b7
       0x000055555587e988 <+72>:	callq  0x5555555c36e0 <[email protected]>
       0x000055555587e98d <+77>:	nopl   (%rax)
       0x000055555587e990 <+80>:	mov    (%rdi),%rax
       0x000055555587e993 <+83>:	cmpq   $0x0,0x58(%rax)
       0x000055555587e998 <+88>:	je     0x55555587e9b0 <_ZN6build24castIN4butl12project_nameEEERKT_RKNS_5valueE+112>
       0x000055555587e99a <+90>:	mov    (%rdi),%rax
       0x000055555587e99d <+93>:	lea    0x2b659c(%rip),%rsi        # 0x555555b34f40 <_ZN6build212value_traitsIN4butl12project_nameEE10value_typeE>
       0x000055555587e9a4 <+100>:	mov    0x58(%rax),%rax
       0x000055555587e9a8 <+104>:	add    $0x8,%rsp
       0x000055555587e9ac <+108>:	jmpq   *%rax
       0x000055555587e9ae <+110>:	xchg   %ax,%ax
       0x000055555587e9b0 <+112>:	lea    0x10(%rdi),%rax
       0x000055555587e9b4 <+116>:	add    $0x8,%rsp
       0x000055555587e9b8 <+120>:	retq   
       0x000055555587e9b9 <+121>:	lea    0x4a320(%rip),%rcx        # 0x5555558c8ce0 <_ZZN6build24castIN4butl12project_nameEEERKT_RKNS_5valueEE19__PRETTY_FUNCTION__>
       0x000055555587e9c0 <+128>:	mov    $0x95,%edx
       0x000055555587e9c5 <+133>:	lea    0x20b04(%rip),%rsi        # 0x55555589f4d0
       0x000055555587e9cc <+140>:	lea    0x3087b(%rip),%rdi        # 0x5555558af24e
       0x000055555587e9d3 <+147>:	callq  0x5555555c36e0 <[email protected]>
    End of assembler dump.
    
    
    opened by max0x7ba 15
  • compiler does not support modules

    compiler does not support modules

    I can manually build a simple c++ modules TS project with my clang++ (7.0.0 trunk), but when i try to use build2 b command it prints "compiler does not support modules" message.

    $ clang++ --version
    clang version 7.0.0- (trunk)
    Target: x86_64-pc-linux-gnu
    Thread model: posix
    InstalledDir: /usr/bin
    

    What can be wrong?

    To enable modules support I added following lines to root buildfile:

    cxx.std = experimental
    
    using cxx
    
    assert $cxx.features.modules 'compiler does not support modules'
    
    mxx{*}: extension = mxx
    cxx{*}: extension = cxx
    
    opened by shitpoet 14
  • ci:

    ci: "error: unable to import target mylib%lib{mylib}"

    bdep --version
    bdep 0.14.0
    libbpkg 0.14.0
    libbutl 0.14.0
    

    I'm seeing this issue (scroll to bottom) when using the build2 ci on virtually all builds.

    I created a new project using bdep new -l c++ -t lib [...]. I diffed it against another build2 project I have (which works fine) and really the only two noteworthy differences are that the former has hxx{export}@./: cxx.importable = false specified (which was autogenerated by bdep v0.14, and I tried removing it to no success), but also it has some more files under it's ./tests subfolder (again, autogenerated). I suspect the tests diff is the trigger in this newer project since it does specify import libs = threadable%lib{threadable}.

    Unrelated question undefined reference to 'pthread_create' Any tip on how to (using build2 practices) correctly setup so that consumers (including tests) link pthread (supporting gcc, clang, clang-apple, clang-emscripten etc)? Getting confused by -pthread & -lpthread, which goes to cxx.coptions or cxx.loptions or cxx.libs etc (google is not super clear, and want to avoid spamming the ci).

    Thanks in advance!

    opened by helmesjo 11
  • Duplication of poptions caused by multiple dependency paths to the same library

    Duplication of poptions caused by multiple dependency paths to the same library

    Context

    Consider a simple project with two libraries and an executable.

    # Root dependency library buildfile
    
    lib{libA}: include/{hxx}{**}
    
    lib{libA}:
    {
      cxx.export.poptions += "-I$src_base"
    }
    
    # Intermediate library buildfile
    
    intf_libs = # Interface dependencies.
    
    import intf_libs += lib{libA}
    
    lib{libB}: $intf_libs
    
    lib{libB}:
    {
      cxx.export.poptions += "-I$src_base"
      cxx.export.libs = $intf_libs
    }
    
    # Consuming executable buildfile
    
    impl_libs = # Implementation dependencies.
    
    import impl_libs += lib{libA} lib{libB}
    
    exe{example}: {cxx}{example} $impl_libs
    

    Observed

    The output from b --verbose=4 shows the following (simplified) commandline. Note that the include path exported by libA is duplicated due to the combination of direct and transitive dependency. clang++ -IX:/.../libA -IX:/.../libB -IX:/.../libA

    Expected

    Ideally, redundant duplicated options should be removed to simplify the command lines. With a number of interdependent libraries, with some libraries occurring as both direct and indirect dependencies of many others, the command line will explode exponentially; even to the point of causing the compiler invocation to fail.

    Suggestion

    There would appear to be two distinct levels at which this could be addressed, perhaps ideally both should be, but the first seems a priority:

    • Remove duplicate library dependencies I couldn't deduce much from a first look at the code so am not clear on the process of variable concatenation with library imports. However, conceptually it would seem to make sense to just accumulate the list of dependencies, which could be done in such a way as to avoid duplicates, and only expand and append their exported variables at the last step, when needed. This seems cleaner than trying to remove redundancies at the level of raw option strings.
    • Remove duplicate options While the above should fix the issue for include paths, other options are not library-specific and therefore can still end up duplicated. So it would be nice to have duplicate removal at the options string level too. This may be less trivial, however, since it's not clear that duplicate entries are necessarily always redundant?

    dup-poptions-repro.zip

    opened by kamrann 11
  • Error building a new project on Fedora

    Error building a new project on Fedora

    Error building a new project on Fedora

    Any help in helping me understand the issue would be greatly appreciated. (Didn't know what to title the issue so feel free to change it.)

    Environment

    b|2 build2 0.13.0-a.0.2756e66940d1 libbutl 0.13.0-a.0.2c67d8c6bb8d host x86_64-redhat-linux

    Note that I first tried version 0.12.0 (installed using dnf) as well and got the same symptoms. Decided to try out the staged version before digging in further.

    Compiler g++ (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)

    Operating system Fedora 32. A fresh install.

    Setup

    Followed the instruction on the main page to create the project and build configuration.

    $ bdep new -t exe -l c++ hello
    $ cd hello
    $ bdep init -C ../hello-gcc cc config.cxx=g++
    

    Then built using b. Which resulted in an error log of about 4.7k lines. Will only post an exert of the logs for now hoping it might be enough.

    c++ hello/cxx{hello}@../hello-gcc/hello/hello/
    In file included from /usr/include/c++/10/bits/exception_ptr.h:39,
                     from /usr/include/c++/10/exception:147,
                     from /usr/include/c++/10/ios:39,
                     from /usr/include/c++/10/ostream:38,
                     from /usr/include/c++/10/iostream:39,
                     from /home/cairns/workspace/hello/hello/hello.cxx:1:
    /usr/include/c++/10/typeinfo:76:5: error: stray ‘#’ in program
       76 |     #define __GXX_TYPEINFO_EQUALITY_INLINE 1
          |     ^
    In file included from /usr/include/c++/10/iostream:38,
                     from /home/cairns/workspace/hello/hello/hello.cxx:1:
    /usr/include/c++/10/x86_64-redhat-linux/bits/c++config.h:2355:11: error: ‘__SIZE_TYPE__’ does not name a type
     2355 |   typedef __SIZE_TYPE__  size_t;
          |           ^~~~~~~~~~~~~
    /usr/include/c++/10/x86_64-redhat-linux/bits/c++config.h:2356:11: error: ‘__PTRDIFF_TYPE__’ does not name a type
     2356 |   typedef __PTRDIFF_TYPE__ ptrdiff_t;
          |           ^~~~~~~~~~~~~~~~
    
    ...
    
    /usr/include/c++/10/initializer_list:47:11: fatal error: definition of ‘class std::initializer_list<_E>’ does not match ‘#include <initializer_list>’
       47 |     class initializer_list
          |           ^~~~~~~~~~~~~~~~
    compilation terminated.
    info: failed to update ../hello-gcc/dir{hello/}
    

    Debugging

    Attempt Nr. 1

    To verify that something wasn't wrong with my environment I decided to compile the file alone. Which turned out to work.

    $ cd ..
    $ mkdir test
    $ cd test
    $ cp ../hello/hello/hello.cxx test.cxx
    $ g++ test.cxx -o test
    $ ./test World
    Hello, World!
    

    Attempt Nr. 2

    I was then wondering if b wasn't using the correct compiler or some other environmental variable so increased the verbosity.

    $ cd ../hello
    $ b -v
    bpkg -v build -d /home/cairns/workspace/hello-gcc --no-fetch --configure-only --keep-out --plan "synchronizing /home/cairns/workspace/hello-gcc/:" --yes [email protected]/home/cairns/workspace/hello
    g++ -I/home/cairns/workspace/hello-gcc/hello -I/home/cairns/workspace/hello -std=c++2a -o ../hello-gcc/hello/hello/hello.o -c -x c++ /home/cairns/workspace/hello/hello/hello.cxx
    ...
    

    The rest of the logs where the exact same as above.

    Decided to try the commands manually to see if I might get some other logs that way. To my surprise neither of the commands yielded any errors at all. So I tried building using b after that and it worked.

    $ bpkg -v build -d /home/cairns/workspace/hello-gcc --no-fetch --configure-only --keep-out --plan "synchronizing /home/cairns/workspace/hello-gcc/:" --yes [email protected]/home/cairns/workspace/hello
    $ g++ -I/home/cairns/workspace/hello-gcc/hello -I/home/cairns/workspace/hello -std=c++2a -o ../hello-gcc/hello/hello/hello.o -c -x c++ /home/cairns/workspace/hello/hello/hello.cxx
    $ b -v
    bpkg -v build -d /home/cairns/workspace/hello-gcc --no-fetch --configure-only --keep-out --plan "synchronizing /home/cairns/workspace/hello-gcc/:" --yes [email protected]/home/cairns/workspace/hello
    g++ -std=c++2a -L /usr/local/lib -o ../hello-gcc/hello/hello/hello ../hello-gcc/hello/hello/hello.o
    ln -s /home/cairns/workspace/hello-gcc/hello/hello/hello /home/cairns/workspace/hello/hello/hello
    $ hello/hello World
    Hello, World!
    

    Making any changes and then building again resulted in the original error. While testing combinations of the commands I narrowed it down to that the important line was:

    g++ -I/home/cairns/workspace/hello-gcc/hello -I/home/cairns/workspace/hello -std=c++2a -o ../hello-gcc/hello/hello/hello.o -c -x c++ /home/cairns/workspace/hello/hello/hello.cxx
    

    Attempt Nr. 3

    Still suspected that something was different with the environment so increased the verbosity further.

    $ b -V
    git -C /home/cairns/workspace/hello status --porcelain
    git -C /home/cairns/workspace/hello cat-file commit HEAD
    bdep sync --hook=1 --verbose 3 --config /home/cairns/workspace/hello-gcc
    mkdir /tmp/bdep-58563-0/
    bpkg --verbose 3 rep-list -d /home/cairns/workspace/hello-gcc
    mkdir /home/cairns/workspace/hello-gcc/.bpkg/tmp/
    rmdir -r /home/cairns/workspace/hello-gcc/.bpkg/tmp/
    bpkg --verbose 3 fetch -d /home/cairns/workspace/hello-gcc --shallow dir:/home/cairns/workspace/hello
    mkdir /home/cairns/workspace/hello-gcc/.bpkg/tmp/
    b --verbose 3 -s info: '/home/cairns/workspace/hello/'
    git -C /home/cairns/workspace/hello status --porcelain
    git -C /home/cairns/workspace/hello cat-file commit HEAD
    sha256sum --version
    info: using 'sha256sum' as the sha256 program, use --sha256 to override
    sha256sum -b /home/cairns/workspace/hello/./manifest
    1 package(s) in 1 repository(s)
    rmdir -r /home/cairns/workspace/hello-gcc/.bpkg/tmp/
    bpkg --verbose 3 build -d /home/cairns/workspace/hello-gcc --no-fetch --configure-only --keep-out --plan "synchronizing /home/cairns/workspace/hello-gcc/:" --yes [email protected]/home/cairns/workspace/hello
    mkdir /home/cairns/workspace/hello-gcc/.bpkg/tmp/
    rmdir -r /home/cairns/workspace/hello-gcc/.bpkg/tmp/
    b --verbose 3 configure: '/home/cairns/workspace/hello/'@'/home/cairns/workspace/hello-gcc/hello/',forward
    git -C /home/cairns/workspace/hello status --porcelain
    git -C /home/cairns/workspace/hello cat-file commit HEAD
    cat >/home/cairns/workspace/hello/build/bootstrap/out-root.build
    rmdir -r /tmp/bdep-58563-0/
    LC_ALL=C g++ -v
    g++ -print-multiarch
    g++ -dumpmachine
    g++ -x c++ -E -
    g++ -x c++ -E -
    LC_ALL=C g++ -print-search-dirs
    LC_ALL=C g++ -x c++ -v -E -
    cxx @/home/cairns/workspace/hello-gcc/
      cxx        [email protected]/usr/lib64/ccache/g++
      id         gcc
      version    10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)
      major      10
      minor      1
      patch      1
      build      20200507 (Red Hat 10.1.1-1) (GCC)
      signature  gcc version 10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)
      checksum   1be04c9eec935b0c2af11992367e83c0aba213e47a0add3d24d07dd19867536e
      target     x86_64-redhat-linux
      runtime    libgcc
      stdlib     libstdc++
      c stdlib   glibc
      inc dirs
        /usr/include/c++/10/
        /usr/include/c++/10/x86_64-redhat-linux/
        /usr/include/c++/10/backward/
        /usr/lib/gcc/x86_64-redhat-linux/10/include/
        /usr/local/include/
        /usr/include/
      lib dirs
        /usr/lib/gcc/x86_64-redhat-linux/10/
        /usr/x86_64-redhat-linux/lib/x86_64-redhat-linux/10/
        /usr/x86_64-redhat-linux/lib64/
        /usr/lib/x86_64-redhat-linux/10/
        /usr/lib64/
        /lib/x86_64-redhat-linux/10/
        /lib64/
        /usr/x86_64-redhat-linux/lib/
        /usr/lib/
        /lib/
        --
        /usr/local/lib/
    bin @/home/cairns/workspace/hello-gcc/
      target     x86_64-redhat-linux
    LC_ALL=C ar --version
    bin.ar @/home/cairns/workspace/hello-gcc/
      ar         [email protected]/usr/bin/ar
      id         gnu
      version    2.34.0-3.fc32
      major      2
      minor      34
      patch      0
      build      -3.fc32
      signature  GNU ar version 2.34-3.fc32
      checksum   dce91e0e0bbb68b751b8e51742920d3d10076b51b7e6fc5fb888dfead3efc4cf
    LC_ALL=C gcc -v
    gcc -print-multiarch
    gcc -dumpmachine
    gcc -x c -E -
    LC_ALL=C gcc -print-search-dirs
    LC_ALL=C gcc -x c -v -E -
    c @/home/cairns/workspace/hello-gcc/
      c          [email protected]/usr/lib64/ccache/gcc
      id         gcc
      version    10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)
      major      10
      minor      1
      patch      1
      build      20200507 (Red Hat 10.1.1-1) (GCC)
      signature  gcc version 10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)
      checksum   10adf4494d036626a3d072d0d78f6118d7f4759500d6f28f519f02d584fc3b80
      target     x86_64-redhat-linux
      runtime    libgcc
      stdlib     glibc
      inc dirs
        /usr/lib/gcc/x86_64-redhat-linux/10/include/
        /usr/local/include/
        /usr/include/
      lib dirs
        /usr/lib/gcc/x86_64-redhat-linux/10/
        /usr/x86_64-redhat-linux/lib/x86_64-redhat-linux/10/
        /usr/x86_64-redhat-linux/lib64/
        /usr/lib/x86_64-redhat-linux/10/
        /usr/lib64/
        /lib/x86_64-redhat-linux/10/
        /lib64/
        /usr/x86_64-redhat-linux/lib/
        /usr/lib/
        /lib/
        --
        /usr/local/lib/
    LC_ALL=C g++ -std=c++2a -print-search-dirs
    LC_ALL=C g++ -std=c++2a -x c++ -v -E -
    cxx [email protected]/home/cairns/workspace/hello-gcc/hello/
      cxx        [email protected]/usr/lib64/ccache/g++
      id         gcc
      version    10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)
      major      10
      minor      1
      patch      1
      build      20200507 (Red Hat 10.1.1-1) (GCC)
      signature  gcc version 10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)
      checksum   1be04c9eec935b0c2af11992367e83c0aba213e47a0add3d24d07dd19867536e
      target     x86_64-redhat-linux
      runtime    libgcc
      stdlib     libstdc++
      c stdlib   glibc
      std        -std=c++2a
      inc dirs
        /usr/include/c++/10/
        /usr/include/c++/10/x86_64-redhat-linux/
        /usr/include/c++/10/backward/
        /usr/lib/gcc/x86_64-redhat-linux/10/include/
        /usr/local/include/
        /usr/include/
      lib dirs
        /usr/lib/gcc/x86_64-redhat-linux/10/
        /usr/x86_64-redhat-linux/lib/x86_64-redhat-linux/10/
        /usr/x86_64-redhat-linux/lib64/
        /usr/lib/x86_64-redhat-linux/10/
        /usr/lib64/
        /lib/x86_64-redhat-linux/10/
        /lib64/
        /usr/x86_64-redhat-linux/lib/
        /usr/lib/
        /lib/
        --
        /usr/local/lib/
    bin [email protected]/home/cairns/workspace/hello-gcc/hello/
      target     x86_64-redhat-linux
    LC_ALL=C ar --version
    bin.ar [email protected]/home/cairns/workspace/hello-gcc/hello/
      ar         [email protected]/usr/bin/ar
      id         gnu
      version    2.34.0-3.fc32
      major      2
      minor      34
      patch      0
      build      -3.fc32
      signature  GNU ar version 2.34-3.fc32
      checksum   dce91e0e0bbb68b751b8e51742920d3d10076b51b7e6fc5fb888dfead3efc4cf
    g++ -I/home/cairns/workspace/hello-gcc/hello -I/home/cairns/workspace/hello -std=c++2a -x c++ -MQ ^ -MD -E -fdirectives-only -MF /home/cairns/workspace/hello-gcc/hello/hello/hello.o.t -o /home/cairns/workspace/hello-gcc/hello/hello/hello.o.ii /home/cairns/workspace/hello/hello/hello.cxx
    g++ -I/home/cairns/workspace/hello-gcc/hello -I/home/cairns/workspace/hello -std=c++2a -E -x c++ -fpreprocessed -fdirectives-only /home/cairns/workspace/hello-gcc/hello/hello/hello.o.ii
    g++ -I/home/cairns/workspace/hello-gcc/hello -I/home/cairns/workspace/hello -std=c++2a -o ../hello-gcc/hello/hello/hello.o -c -fdirectives-only /home/cairns/workspace/hello-gcc/hello/hello/hello.o.ii
    ...
    

    Turned out that the commands aren't quite the same with it split into three parts. Running them manually the first part doesn't log anything. The second produced a massive blob that looks like the final code. The third produces the errors as expected.

    Now I don't know how to proceed which is why I'm reaching out for help.

    opened by CairX 11
  • b stack buffer overrun detected when trying to setup an unusual configuration (windows)

    b stack buffer overrun detected when trying to setup an unusual configuration (windows)

    I didn't manage to reproduce this with a simpler case for now (lack of time, I'll try to do more soon). I don't think it's relative to the actual library used, but that's how I got there.

    How to reproduce:

    1. On Windows, with build2 v0.11.0, using msvc 16.1 (used for all the following and the build2 install).
    2. build and install boost 1.69.0 somewhere on the disk (using b2) (or mayb just download a binary package? I didn't try that yet)
    3. Add a pkg-config file for boost in the lib/pkgconfig directory of your boost install. Here is what I used: https://pastebin.com/7A01nCw7
    4. bdep new boostuser && cd boostuser
    5. Add depends: libboost >= 1.69.0 in manifest.
    6. Create the configuration this way, just replace the paths to boost install (yep, this is weird):
    bdep init ?sys:libboost/* -C ../build-boostuser cc config.cxx.loptions="/LIBPATH:G:\tools\boost\boost_install\lib" config.cxx.poptions="/I G:\tools\boost\boost_install\include\boost-1_69"
    

    This leads to an error because for some reason ?sys:libboost/* is ignored even if put at the end of the line. (see #39 )

    1. Insist again: bdep init ?sys:libboost/* => lead to the error

    Observed:

    PS G:\tmp\test_build2_unpackaged\boostuser> bdep init ?sys:libboost/* -C ../build-boostuser cc config.cxx.loptions="/LIBPATH:G:\tools\boost\boost_install\lib" config.cxx.poptions="/I G:\tools\boost\boost_install\include\boost-1_69"   initializing in project G:\tmp\test_build2_unpackaged\boostuser\
    created configuration G:\tmp\test_build2_unpackaged\build-boostuser\ 1 default,forwarded,auto-synchronized
    error: unknown dependency libboost >= 1.69.0 of package boostuser
      info: repository dir+file:///G:/tmp/test_build2_unpackaged/boostuser appears to be broken
      info: or the repository state could be stale
      info: run 'bpkg rep-fetch' to update
    info: while satisfying boostuser/0.1.0-a.0.19700101000000
    PS G:\tmp\test_build2_unpackaged\boostuser> bdep init ?sys:libboost/*                                                initializing in project G:\tmp\test_build2_unpackaged\boostuser\
    synchronizing:
      configure sys:libboost/*
      new boostuser/0.1.0-a.0.19700101000000
    error: process b terminated abnormally: stack buffer overrun
    

    With --verbose 4 : https://pastebin.com/zGWukPx0

    opened by Klaim 11
  • b crash relating to config.bin.lib value

    b crash relating to config.bin.lib value

    I recently realized I'd been building a number of libs in both static and shared mode, despite only needing to consume them as shared. I modified build/config.build in my configuration to specify config.bin.lib = shared, and set config.bin.lib = static in the config.build of one specific package. These combined changes have resulted in the following output from b update:

    trace: create_new_target: new target C:\Kantan\build\msvc-debug-asan\kantan\kantan\component-core\source\dbg\obj{visualizer_state} for prerequisite C:\Kantan\build\msvc-debug-asan\kantan\kantan\component-core\source\dbg\obj{visualizer_state}
    Assertion failed: m != nullptr, file C:\build2\build\build2-toolchain-0.15-a.0\build2-0.15.0-a.0.20220511070701.53234fea9cd6\libbuild2\algorithm.cxx, line 354
    

    I'll try to update to the latest staged toolchain soon, but let me know if there's any other tests I could do to provide some more information.

    bug 
    opened by kamrann 10
  • vs2019 x64 win10

    vs2019 x64 win10

    in libpkgconf-1.6.3+4\libpkgconf\config.h.in version.in libbutl-0.13.0\libbutl\version.hxx.in version.in libodb-sqlite-2.5.0-b.19\odb\sqlite\version-build2.hxx.in version.in libodb-2.5.0-b.19\odb\version-build2.hxx.in in build2-0.13.0\libbuild2\config.hxx.in version.in libbpkg-0.13.0\libbpkg\version.hxx.in version.in build2-0.13.0\libbuild2\version.hxx.in C:\Users\Documents\build2\build2-toolchain-0.13\bdep-0.13.0\bdep\new-options.cxx(3617): error C2220: C:\Users\Documents\build2\build2-toolchain-0.13\bdep-0.13.0\bdep\new-options.cxx(3617): warning C4819

    opened by yangxingpping 10
  • Broken repository state due to case-sensitive paths on Windows

    Broken repository state due to case-sensitive paths on Windows

    Output

    > bpkg fetch
    fetching dir:D:\Coding\Kantan\kantan-build2
    [various prerequisite fetches here]
    fetching dir:D:\coding\kantan\build2-repro
    fetching dir:D:\coding\kantan\kantan-build2
    error: external package kantan/0.1.0 is available from two repositories
      info: repository dir+file:///D:/Coding/Kantan/kantan-build2
      info: repository dir+file:///D:/coding/kantan/kantan-build2
    warning: repository state is now broken and will be cleaned up
      info: run 'bpkg rep-fetch' to update
    
    > bpkg list
    dir:D:\Coding\Kantan\kantan-build2 dir+file:///D:/Coding/Kantan/kantan-build2
    dir:D:\coding\kantan\build2-repro dir+file:///D:/coding/kantan/build2-repro
    dir:D:\coding\kantan\kantan-build2 dir+file:///D:/coding/kantan/kantan-build2
    

    Further info/questions

    I'm on Windows 10, and using Powershell. It's not clear precisely what sequence of actions leads to this, though it has happened a number of times, mostly after adding a new external git prerequisite to my project's repositories.manifest and then trying to update. I'm also reasonably confident that at no point would I have directly typed the lower case version of the above paths in any command.

    Two other minor things:

    • Does external package have some specific meaning in the above output? It seems a little strange to me since this is a package that lives inside the project repository.
    • The diagnostic's suggestion to run the exact same command that just gave the error is a little confusing!
    opened by kamrann 10
  • error: module name expected instead of <punctuation>

    error: module name expected instead of

    When compiling, b attempts to scan every cpp file in an external non-build2 dependency (which is only included via -I), and it incorrectly throws the error:

    …/opt/ace/build/x86_64-apple-darwin/ace/Task_T.cpp:101:43: error: module name expected instead of <punctuation>
      info: while scanning …/RACM_Interfc/cxx{RACM_Utils.cpp}
    

    while scanning this line:

    template<ACE_SYNCH_DECL, class TIME_POLICY> ACE_Module<ACE_SYNCH_USE, TIME_POLICY> *
    ACE_Task<ACE_SYNCH_USE, TIME_POLICY>::module (void) const
    {
      ACE_TRACE ("ACE_Task<ACE_SYNCH_USE, TIME_POLICY>::module");
      return this->mod_;
    }
    

    It's incorrectly recognizing module as a keyword. I have cxx.std = c++14 in my root.build. How do I stop this?

    opened by alexchandel 10
  • Surprising `bdep status` output when linked configurations are involved

    Surprising `bdep status` output when linked configurations are involved

    If I create the XSD build setup per the README.md (with three build configurations) and then run bdep status -a I get the following output:

    $ bdep status -a
    in configuration @gcc8-host:
    xsd configured 4.2.0-b.4.20220915132437.f235c0a6c7f3
    
    in configuration @gcc8-target:
    libxsd configured 4.2.0-b.4.20220915132437.f235c0a6c7f3
    libxsd-tests configured 4.2.0-b.4.20220915132437.f235c0a6c7f3
    xsd-tests configured 4.2.0-b.4.20220915132437.f235c0a6c7f3
    xsd-examples configured 4.2.0-b.4.20220915132437.f235c0a6c7f3
    
    in configuration @gcc8-install:
    xsd configured 4.2.0-b.4.20220915132437.f235c0a6c7f3
    xsd [/home/boris/work/xsd/builds/gcc8-host/] configured 4.2.0-b.4.20220915132437.f235c0a6c7f3
    

    Note that output for the gcc8-install with two xsd.

    Digging a bit deeper, apparently this is how bpkg-status works for the packages specified on the command line (in contrast to -a): "the --link option is only meaningful for -a mode and for explicitly specified packages is implied".

    opened by boris-kolpackov 0
  • Set output directory to be inside the projects directory

    Set output directory to be inside the projects directory

    I am new to build2 and are currently following along the toolchain introduction. There, the build output (and i think the build configs later as well) are put in directories parallel to the project e.g.

    demo/ <-- actual project 
    demo-out/ <-- build output of the project above 
    

    Is it currently possible to set the output path to be inside the actual projects directory?

    demo/
    - build/
      - ...
    - out/ <-- demo.exe ect. are put into here
    - src/
      - demo.cpp
      - buildfile
    - buildfile
    
    opened by KabelitzJ 3
  • msvc: build2 fail with '__cpp_modules' is reserved

    msvc: build2 fail with '__cpp_modules' is reserved

    I have been using CMake for a long time and I am looking for an alternative for CXX modules. Build2 seems to meet almost all my requirements. It's brilliant.

    Unfortunately, it currently fails with MSVC. This is probably a known issue but I could not see it reflected in the issues board:

    # Suppress warnings coming from external libraries.
    #
    cxx.internal.scope = current
    
    # Some compilers (e.g. gcc) require that experimental features be enabled.
    #
    cxx.std = experimental
    cxx.features.modules = true
    
    assert $cxx.features.modules "no modules support for $cxx.signature"
    
    using cxx
    
    mxx{*}: extension = cero
    
    # Assume headers are not importable unless stated otherwise.
    #
    hxx{*}: cxx.importable = false
    
    # The test target for cross-testing (running tests under Wine, etc).
    #
    test.target = $cxx.target
    
    C:\Users\wroy\Desktop\cero\cero-std\main.cero: error C2220: the following warning is treated as an error
    C:\Users\wroy\Desktop\cero\cero-std\main.cero: error C2220: the following warning is treated as an error
    C:\Users\wroy\Desktop\cero\cero-std\main.cero: warning C4117: macro name '__cpp_modules' is reserved, '#define' ignored
    C:\Users\wroy\Desktop\cero\cero-std\main.cero: warning C4117: macro name '__cpp_modules' is reserved, '#define' ignored
    
    modules 
    opened by wroyca 9
  • Add ability to pass additional

    Add ability to pass additional "global" options/arguments to all tests from command line

    This desire may seem strange at first since, in the general case, we may be running tests for multiple unrelated project. But it's also not uncommon to test only a specific project (or run a subset of its tests or even a single test) which may use a common testing framework (for example, catch2) that provides its own main() implementation and recognizes some options or even arguments (e.g., output format, which tests to run, etc). Being unable to pass this information from the command line seems surprising.

    enhancement 
    opened by boris-kolpackov 0
  • Inconsistent bpkg behavior, test and clean operations are failing

    Inconsistent bpkg behavior, test and clean operations are failing

    Since sometime, I observed that bpkg behaves differently in configs created using bdep config create and configs created by bpkg create. The inconsistency is highlighted below:

    -----------------------------------------------------------------
    In config created by bdep
    -----------------------------------------------------------------
    >  bpkg build doctest
    c++ doctest-2.4.9/tests/cxx{tutorial}
    c++ doctest-2.4.9/tests/cxx{subcases}
    ld doctest-2.4.9/tests/exe{subcases}
    ld doctest-2.4.9/tests/exe{tutorial}
    updated doctest/2.4.9
    >  bpkg clean doctest
    error: package name argument expected                 ----------> Why?
     info: run 'bpkg help pkg-build' for more information
    
    >  bpkg --verbose=5 clean doctest
    ... (Wall of text)
    configuration"."auto_sync" FROM "configuration" WHERE "configuration"."path" = ?
    trace: load_implicit: COMMIT
    trace: open: PRAGMA locking_mode = EXCLUSIVE
    trace: open: BEGIN EXCLUSIVE
    trace: open: SELECT "version", "migration" FROM "main"."schema_version" WHERE "name" = ?
    trace: open: COMMIT
    trace: load_implicit: BEGIN
    trace: load_implicit: SELECT "configuration"."id", "configuration"."name", "configuration"."type", "configuration"."path", "configuration"."relative_path", "configuration"."default", "configuration"."forward", "configuration"."auto_sync" FROM "configuration" WHERE "configuration"."path" = ?
    trace: load_implicit: COMMIT
    bpkg --verbose 5 build --no-fetch --no-refinement --no-private-config 125 --noop-exit 124 --configure-only --keep-out --plan "synchronizing /home/build/swat/x64/gcc-debug-shared/:" --yes
    trace: pkg_build: configuration: ./
    error: package name argument expected                ----------> Why?
     info: run 'bpkg help pkg-build' for more information
    rmdir -r /tmp/bdep-51302-0/
    /home/build/swat/x64/gcc-debug-shared/build/bootstrap/pre-bdep-sync.build:10:9: trace: parser::source: leaving <stdout>
    trace: run_finish: process bdep exited with code 1
    
    -----------------------------------------------------------------
    In config created by bpkg
    -----------------------------------------------------------------
    >  bpkg build doctest
    bpkg build doctest
    c++ doctest-2.4.9/tests/cxx{subcases}
    c++ doctest-2.4.9/tests/cxx{tutorial}
    ld doctest-2.4.9/tests/exe{subcases}
    ld doctest-2.4.9/tests/exe{tutorial}
    updated doctest/2.4.9
    >  bpkg clean doctest
    rm doctest-2.4.9/tests/exe{tutorial}
    rm doctest-2.4.9/tests/exe{subcases}
    rm doctest-2.4.9/tests/obje{tutorial}
    rm doctest-2.4.9/tests/obje{subcases}
    cleaned doctest/2.4.9                           -------------> Works but why? Whats the difference
    

    I observed similar differences with bpkg test as well. Any ideas?

    > bpkg --version
    bpkg 0.15.0
    libbpkg 0.15.0
    libbutl 0.15.0
    Copyright (c) 2014-2022 the build2 authors.
    This is free software released under the MIT license.
    
    bug 
    opened by Swat-SomeBug 4
  • Aborted install script can't be continued and partial installation can't be uninstalled

    Aborted install script can't be continued and partial installation can't be uninstalled

    I ran build2-install-0.15.0.sh and during bpkg-stage one of the downloads got stuck and I ended up terminating the script. If I try to rerun the script I get:

    error: staged executable name 'b-stage' clashes with existing /usr/local/bin/b-stage
    info: specify alternative staged executables name suffix with --stage-suffix
    

    Running the script with --uninstall I get:

    + bpkg uninstall --all
    build2-install-0.15.0.sh: line 68: bpkg: command not found
    

    So I tried running it with --stage-suffix mystage, which ran through but I must be misunderstanding what that parameter is used for. Just to test it I ran --uninstall, which worked, and then again the script without any parameters and I got the staged name clash again. Also after the --uninstall run /usr/local/bin still contains bpkg-stage and b-stage.

    What I'd like to achieve is either to be able to continue the aborted installation or get a clean uninstall so I can run the install script properly.

    enhancement 
    opened by nhkode 2
Owner
The build2 project
Cross-platform toolchain for building and packaging C/C++ code
The build2 project
A collection of commonly used code for Algorithms Context written in C++

Algo Template CPP A collection of commonly used code for Algorithms Contest written in C++. Number int from_bin(string bin) string to_bin(int num) int

Grey Wang 2 Feb 7, 2022
Code::Blocks template for custom launcher executable.

Launcher Code::Blocks template for custom launcher executables. This is a basic Code::Blocks project for creating authentic Windows executables. Inclu

Federico Cappelletti 1 Feb 5, 2022
this lib with 26 template container and 10 kinds of algorithm, it is a good lib for study and usage

simple stl this lib simplify the achievement detail of common container, but add the container variety, the whole code partily follow Google Style. Em

wujiazheng 7 Mar 10, 2022
Quick and dirty templating and docs generation.

Rader Quick and dirty templating and docs generation. Rader is a pre-processing (or post-processing) utility written in portable C++ 20 (only using st

Nolram 2 Dec 19, 2021
Improved and configurable drop-in replacement to std::function that supports move only types, multiple overloads and more

fu2::function an improved drop-in replacement to std::function Provides improved implementations of std::function: copyable fu2::function move-only fu

Denis Blank 399 Sep 19, 2022
LLVM libc++ without exception and RTTI, specifically for Android.

libc++ LLVM libc++, specifically for Android, removing exception and RTTI support. Source code is extracted from AOSP's llvm-project repository: git c

John Wu 46 Sep 21, 2022
expected lite - Expected objects in C++11 and later in a single-file header-only library

expected lite: expected objects for C++11 and later expected lite is a single-file header-only library for objects that either represent a valid value

Martin Moene 231 Sep 19, 2022
gsl-lite – A single-file header-only version of ISO C++ Guidelines Support Library (GSL) for C++98, C++11, and later

gsl-lite: Guidelines Support Library for C++98, C++11 up metadata build packages try online gsl-lite is an implementation of the C++ Core Guidelines S

gsl-lite 754 Sep 20, 2022
C++11/14/17 std::optional with functional-style extensions and reference support

optional Single header implementation of std::optional with functional-style extensions and support for references. Clang + GCC: MSVC: std::optional i

Sy Brand 672 Sep 16, 2022
optional lite - A C++17-like optional, a nullable object for C++98, C++11 and later in a single-file header-only library

optional lite: A single-file header-only version of a C++17-like optional, a nullable object for C++98, C++11 and later Contents Example usage In a nu

Martin Moene 348 Aug 10, 2022
span lite - A C++20-like span for C++98, C++11 and later in a single-file header-only library

span lite: A single-file header-only version of a C++20-like span for C++98, C++11 and later Contents Example usage In a nutshell License Dependencies

Martin Moene 404 Sep 21, 2022
string_view lite - A C++17-like string_view for C++98, C++11 and later in a single-file header-only library

string_view lite: A single-file header-only version of a C++17-like string_view for C++98, C++11 and later Contents Example usage In a nutshell Licens

Martin Moene 332 Sep 23, 2022
variant lite - A C++17-like variant, a type-safe union for C++98, C++11 and later in a single-file header-only library

variant lite: A single-file header-only version of a C++17-like variant, a type-safe union for C++98, C++11 and later Contents Example usage In a nuts

Martin Moene 214 Sep 22, 2022
42 Cursus - Libft: My implementation of some useful C functions and some additional ones to use it in future projects of 42.

42 Cursus - libft Info My implementation of some useful C functions and some additional ones to use it in future projects of 42. Status: still updatin

izenynn 7 Jul 21, 2022
gsl-lite – A single-file header-only version of ISO C++ Guidelines Support Library (GSL) for C++98, C++11, and later

gsl-lite: Guidelines Support Library for C++98, C++11 up metadata build packages try online gsl-lite is an implementation of the C++ Core Guidelines S

gsl-lite 753 Sep 13, 2022
This project is pretty straightforward, you have to recode printf. You will learn what is and how to implement variadic functions. Once you validate it, you will reuse this function in your future projects.

100/100 Introduction to ft_printf This is the third project in the 1337 Curriculum #42network . This project is pretty straight forward, recode the pr

Zakaria Yacoubi 4 May 27, 2022
A template C project using CMAKE, logging library and basic memory handling.

C Project template Aim of this Repository is to create a template repository for C executable projects with following properties: Cmake project Loggin

Aditya Singh Rathore 6 May 23, 2022
A thread-safe, easy-to-use, utility for sending and receiving notifications. It allows you to decouple different modules of your application.

NotificationManager NotificationManager is a thread-safe, easy-to-use utility for sending and receiving notifications. It allows you to decouple diffe

Carlos Aragonés 6 Dec 27, 2021
Bsl - Rust 2018 and C++20, "constexpr everything", AUTOSAR compliant header-only library intended to support the development of critical systems applications

Description The Bareflank Support Library (BSL) is a Rust 2018 and C++20, "constexpr everything", AUTOSAR compliant header-only library intended to su

Bareflank 70 Sep 13, 2022