deplinenoise / tundra Goto Github PK
View Code? Open in Web Editor NEWTundra is a code build system that tries to be accurate and fast for incremental builds
License: MIT License
Tundra is a code build system that tries to be accurate and fast for incremental builds
License: MIT License
Latest code returns paths that has mixed slashes (for example zenic/Test\Foo\Bar) It would be best if it was forward slashes only in all paths.
Tundra can already build foreign programs just fine, but a cross-compilation aware configuration is needed e.g. for consoles when compiling tools.
Currently something cryptic about type conversions in the C code is output for an error message. Should really say: "no such dir".
Because Lua already has defined all the strings we need (filenames, annotations and so on) it doesn't make sense to copy them. A better idea would be just to make sure they're kept alive on the Lua side and then use the pointers directly.
It would be very nice if Depends={"Fiskrens"} was everything required to use the fiskrens lib. So if there was some kind of way to specify the "Use headers" needed for using the lib, in addition to the headers needed to actually compile it, that'd be awesome.
repro:
rm -rf tundra-output
rm .tundra-*
tundra --ide-gen=msvc80
=> fail
The current project generation isn't very good for C# projects, they need special care and pampering via custom MSBuild files so intellisense works.
Support storing stuff such as:
Essentially command line arguments into a config file. Provide a --config
option similar to git that allows you to set/list these options.
Bootstrapping tundra on msvc2008 fails due to msvc-winsdk requires 2010 sdk.
There is currently only one projects that builds and the other projects are just stubs that hold source files. Debugging now means setting an executable by hand on one of these projects.
The native code (especially engine.c
) should be split up more clearly into various modules:
Also, engine is a misleading name as it is just a shell for data collection and starting the build; the actual build engine is in build.c
. The engine file should be renamed to something else.
Use a collision map to avoid errors such as this:
Cc foo.o: file foo.o is already an output of Cc foo.o
This happens if you do e.g.
Program { Name = "foo", Sources = { "baz.c" } }
Program { Name = "bar", Sources = { "baz.c" } }
Example:
ExternalLib {
Name = "directx",
Propagate = {
Libs = { { ... ; Config = "win32-*-*" } },
Includes = { ... },
},
}
SharedLibrary {
Name = "foo",,
Depends = { "directx", ... }, -- automatically pull in dx libs/includes
}
It's confusing
E.g. MacOSX ar doesn't like just updating the same archive over and over again.
OverwriteOutputs
that defaults to trueTundra should use the unix philosophy of not printing anything to stdout if the operation completes as expected. So a successful tundra build should look something like this:
$ tundra
$
A clean:
$ tundra -c
$
A failed build:
$ tundra
Error C1234: foo bar myfile.c (1234)
etc...
$
Easiest implementation is probably to write stdout/stderr to file and then dump it if an error is detected (a regex?)
If this is a performance issue (shouldn't be for incremental builds as the output usually is tiny), then a --silent option could be added which enables this behavior.
This is needed for byproduct files such as PDBs, .ext files etc.
Tundra should automatically detect the number of core available and use that many threads.
This is desirable so projects can avoid relinking e.g against shared libraries when only their public interfaces have changed.
The way to implement this is to let the frontend hook in a sign function on the link phase for the shared libraries so they can override the exposed file signature on the .dll and .lib files (or .so, .dylib files).
Here's what we could accelerate with the change journal:
The drawbacks are:
Relative to $(SolutionDir) is probably preferable, but absolute works fins too..
If we can figure out a way to cleanly cache the configuration up to the point where the declarative input is sent to the node generators, it should be totally possible to cache this state to disk and reuse it for subsequent incremental builds.
This would primarily mean that all file globs were cached, so an alternative way to implement this is to cache on the glob level.
E.g. referencing sources with ../../
will create broken output paths and what not and probably trigger native code errors due to path normalization issues. We should allows paths such as this in the best way possible. Also support fully qualified paths.
The headers in the relation cache could be persisted to disk to speed up implicit dependency scanning on the next run.
Care must be taken though as this process is already very fast, a few hundred headers are scanned from disk cache in a matter of 60-100 milliseconds even on NTFS. When the project is so big that headers are ejected from the disk cache however, this will provide more gains as we don't have to run around opening files to see what headers they include.
It would be useful to have static libraries "Depends" work recursively, so
StaticLibrary { Name = "foo", ... }
StaticLibrary { Name = "bar", Depends = { "foo" }, ... }
Program = { Name = "qux", Depends = { "bar" }, ... }
Would automatically link qux
with foo
.
Tundra should have a way to dump all elements of the signing process in human-readable form to facilitate debugging of build issues.
Repro:
tundra -c and deleting all .tundra-* files is a workaround.
Convenient to get code generators and tools to always build.
Support Application and Framework bundle generation.
e.g.
$ tundra foo-bar foo-bar: no such configuration, choose from these: - win32-msvc - macosx-clang - ...
Currently files sent to env:make_node(.. OutputFiles = { ... } } will always be deleted before the run or when doing a tundra clean.
This is the wanted behavior in many situations but if you want to generate something to be included in the source tree (that generates something that takes a long time to generate) this is not wanted so the possibility to override the cleaning of files by adding another flag to make_node would be useful.
Currently external environment strings are duplicated for all nodes which wastes a lot of memory. These are immutable and could be kept in a hash table instead.
Need a cleaner way to filter general lists of sources in custom node handlers and syntax nodes; see osx-bundle for example. The Resources list handling in there is awkward when there are source generators (functions) in the list.
Some better structured helper functions in nodegen.lua could help with this.
After a handful incremental builds of rev6 I get the following error:
:!tundra 2>&1| tee /var/folders/2Y/2Y8Mu557HiOQdnfUtC388U+++TI/-Tmp-/v644169/18
ld: in tundra-output/macosx-clang-debug-default/r6_ui.a(), archive member '' with length 0 is
not mach-o or bitcode
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Cc tundra-output/macosx-clang-debug-default/Source/r6_ui_test/ui_test2.o
Cc tundra-output/macosx-clang-debug-default/Source/r6_ui/rs_ui_render_glut.o
StaticLib tundra-output/macosx-clang-debug-default/r6_ui.a
Program tundra-output/macosx-clang-debug-default/ui_test2
*** build failed, 4 jobs run
(1 of 7): ld: in tundra-output/macosx-clang-debug-default/r6_ui.a(), archive member '' with le
ngth 0 is not mach-o or bitcode
It appears as if some random object file is corrupted.
tundra -c and then a rebuild solves the problem.
E.g.
root/tundra.lua
root/foo_dir/
cd root/foo_dir
tundra <-- can't find tundra.lua i pwd, so go up a level and try again until at root or succeeded.
Currently one need to change in generic-cpp.lua to add a custom extension (in my case .vcc that builds as a regular C file) but also other file types (like assembler for example) would be nice if you just can override in a simpler way.
This is convenient for users that don't want to hack on tundra and should speed up startup as well as no scripts need to be read from the tundra install dir.
This happens because the individual child processes do not synchronize when writing to the terminal stream. One approach would be to create a bidirectional pipe and handle I/O this way, but this creates pretty sloppy stalls for error messages and such. It's however the only way I can think of.
For small builds having a separate Units file might be overkill.
Input signing currently is serialized on file access which is not ideal.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.