aboutsummaryrefslogtreecommitdiff
path: root/libbuild2/cc/init.cxx
AgeCommit message (Collapse)AuthorFilesLines
2022-10-10Preparatory work for public/private variable distinctionBoris Kolpackov1-3/+4
We still always use the public var_pool from context but where required, all access now goes through scope::var_pool().
2022-06-29Save cc.type in pkg-config filesBoris Kolpackov1-5/+6
2022-04-13Prune library graph traversal for recursively-binless librariesBoris Kolpackov1-9/+13
2022-03-28Add ability to customize pkg-config header and library search pathsBoris Kolpackov1-0/+7
Specifically, {cc,c,cxx}.pkgconfig.{include,lib} variables specify header (-I) and library (-L) search paths to use in the generated .pc files instead of the default install.{include,lib}. Relative paths are resolved as install paths.
2021-10-04Add support for treating specific libraries as always internalBoris Kolpackov1-0/+1
2021-10-01Add notion of internal scope, translate external -I to -isystem or equivalentBoris Kolpackov1-0/+20
2021-08-11Optimize process_libraries() some moreBoris Kolpackov1-0/+3
2021-06-30Move symbol exporting .def file rule to bin.def module, add support for MinGWBoris Kolpackov1-2/+4
The bin.def module is automatically loaded by the c and cxx modules for the *-win32-msvc target architecture. This allows automatically exporting all symbols for all Windows targets using the following setup (showing for cxx in this example): lib{foo}: libul{foo}: {hxx cxx}{**} ... lib{foo}: def{foo}: include = ($cxx.target.system == 'win32-msvc') def{foo}: libul{foo} if ($cxx.target.system == 'mingw32') cxx.loptions += -Wl,--export-all-symbols That is, we use the .def file generation for MSVC and the built-in support (--export-all-symbols) for MinGW. But it is also possible to use the .def file generation for MinGW. In this case we need to explicitly load the bin.def module (which should be done after loading c or cxx) and using the following setup: using bin.def # In root.build. lib{foo}: libul{foo}: {hxx cxx}{**} ... lib{foo}: def{foo}: include = ($cxx.target.class == 'windows') def{foo}: libul{foo}
2021-05-04Replace int_ with intf_ and imp_ with impl_ in namesBoris Kolpackov1-1/+1
2021-01-30Rework include translation supportBoris Kolpackov1-0/+8
See the config.cxx.translate_include variable documentation in cxx/init.cxx for details.
2020-08-24Use representation when passing target_triplet as hintBoris Kolpackov1-1/+1
2020-07-16Save original compiler path/mode in {c,cxx}.config.path/modeBoris Kolpackov1-8/+8
It turns out that when propagating {c,cxx}.config in tests we don't want to propagate any options (such as *.std) that have been folded into our project's mode.
2020-07-01Add *.export.imp_libs to get rid of dual *.export.libs semanticsBoris Kolpackov1-0/+1
2020-06-09Move C++ modules sidebuild to build/cc/build/modules/ subdirectoryBoris Kolpackov1-8/+18
2020-05-27Initial support for ad hoc recipes (still work in progress)Boris Kolpackov1-3/+3
2020-04-27Rework tool importation along with cli moduleBoris Kolpackov1-1/+1
Specifically, now config.<tool> (like config.cli) is handled by the import machinery (it is like a shorter alias for config.import.<tool>.<tool>.exe that we already had). And the cli module now uses that instead of custom logic. This also adds support for uniform tool metadata extraction that is handled by the import machinery. As a result, a tool that follows the "build2 way" can be imported with metadata by the buildfile and/or corresponding module without any tool-specific code or brittleness associated with parsing --version or similar outputs. See the cli tool/module for details. Finally, two new flavors of the import directive are now supported: import! triggers immediate importation skipping any rule-specific logic while import? is optional import (analogous to using?). Note that optional import is always immediate. There is also the import-specific metadata attribute which can be specified for these two import flavors in order to trigger metadata importation. For example: import? [metadata] cli = cli%exe{cli} if ($cli != [null]) info "cli version $($cli:cli.version)"
2020-03-31Switch to project variable visibility by defaultBoris Kolpackov1-12/+12
2020-03-17Rework config::{omitted,required,optional}() into unified config_lookup()Boris Kolpackov1-7/+8
2020-02-07Drop copyright notice from source codeKaren Arutyunov1-1/+0
2020-01-29Rename module_base to module, redo module boot/init argument passingBoris Kolpackov1-16/+12
2020-01-28Use scope::var_pool()Boris Kolpackov1-27/+27
2020-01-27Improve module loading APIBoris Kolpackov1-35/+16
2019-10-21Add more information on C and C++ compiler mode options to manualBoris Kolpackov1-0/+2
2019-10-18Add ability to specify "compiler mode" options as part of config.{c,cxx}Boris Kolpackov1-0/+10
Such options are (normally) not overridden by buildfiles and are passed last (after cc.coptions and {c,cxx}.coptions) in the resulting command lines. They are also cross-hinted between config.c and config.cxx. For example: $ b config.cxx="g++ -m64"
2019-08-28Move cc build system module to separate libraryKaren Arutyunov1-0/+493