Age | Commit message (Collapse) | Author | Files | Lines |
|
So now we can do:
doc{INSTALL}@./: install = false
Note that so far that's the only place where we support out-qualification.
Grep for @@ OUT to see other places.
|
|
We need this for the out-qualified target syntax:
h{config}@./: install = false
|
|
We only really used pairs.
|
|
This is handy, for example, when installing headers:
install.include = $install.include/foo
install.include.subdirs = true
The base for calculating the subdirectories is the scope where the
subdirs value is set.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hardcoding separators as in "build/root.build" is now a big no-no.
|
|
This solves the problem of changing path spelling on platforms with case-
insensitive filesystems.
For example, you may build a project in the current working directory without
specifying any paths. This means the current working directory will be used as
the project's root. On Windows this could be C:\x.
Now you are building another project that imports the above project and you
specify config.import.x variable pointing to the above build. But you are lazy
to type capital C so you spell it as config.import.x=c:\x.
What happens now is the value from config.import.x is used as the project
root. And now it is a different spelling compared to your original build. This
is not a problem when the build system itself is concerned -- it is smart
enough to use case-insensitive comparison. However, we often use roots to
derive other things, say, -I options that we pass to compilers. And these
options are normally no longer treated as (case-insensitive) paths. If they
are hashed and the result stored in depdb, then we end up with rebuilds that
are triggered by changes from C:\ to c:\.
|
|
|
|
|
|
There is really no use seeing this stuff.
|
|
|
|
|
|
|
|
|
|
|
|
This will make things more convenient on Windows provided we use "sane"
paths (no spaces, no (), etc).
|
|
|
|
|
|
|
|
Since there is no guarantee that the target is part of the linker's checksum.
|
|
|
|
|
|
The 'projects and subprojects' semantics resulted in some counter-intuitive
behavior. For example, in a project with tests/ as a subproject if one builds
one of the tests directly with a non-global override (say C++ compiler), then
the main project would be built without the overrides. I this light,
overriding in the whole amalgamation seems like the right thing to do. The
old behavior can still be obtained with scope qualification, for example:
b ./:foo=bar
|
|
This way we can group them semantically which results in easier to
understand config.build output.
|
|
|
|
So now we can do:
if true
print true
else
print false
Instead having to do:
if true
{
print true
}
else
{
print false
}
|
|
|
|
This way, when we, for example, change the C++ compiler (which hinted these
values), they will be automatically adjusted as well.
|
|
The current model fell apart when we modified values directly.
|
|
Now can write:
if ($build.version > 30000)
|
|
|
|
|
|
|
|
This way we don't load/configure what we don't need.
|
|
In the end, having libs{} be the DLL with import library being its member is
more natural than making libs{} the import library and having dll{} as its
member.
|
|
|
|
|
|
This way we can specify static library-specific defines which are necessary
to handle DLL export.
|
|
Specifically:
* objso{} and libso{} target types have been renamed to objs{} and libs{}
* obje{} has been added (so now we have obje{}, obja{}, and objs{})
* obje{} is now used for building exe{}
* object file extensions have been changed to use "hierarchical extensions"
that reflect the extension of the corresponding exe/lib target (instead of
the -so suffix we used), specifically:
obje{}: foo.o, (UNIX), foo.exe.o (MinGW), foo.exe.obj (Windows)
obja{}: foo.a.o (UNIX, MinGW), foo.lib.obj (Windows)
objs{}: foo.so.o (UNIX), foo.dylib.o (Darwin), foo.dll.o (MinGW),
foo.dll.obj (Windows)
|
|
Semantically, these are similar to variable overrides and are essentially
treated as "templates" that are applied on lookup to the "stem" value that is
specific to the target type/name. For example:
x = [string] a
file{f*}: x =+ b
sub/:
{
file{*}: x += c
print $(file{foo}:x) # abc
print $(file{bar}:x) # ac
}
|
|
While on some platforms they sometimes can be the same, they could also
be built differently (e.g., based on command line macros, etc). I guess
we could compare the set of options and if they are identical, then use
the same file. But that will complicate things quite a bit, so maybe in
version 2.
|
|
|