deplinenoise / tundra Goto Github PK

e.g.

$ tundra foo-bar
foo-bar: no such configuration, choose from these:
  - win32-msvc
  - macosx-clang
  - ...

It's confusing

Repro:

1. build e.g. rev6 with tundra (win32-msvc)
2. add
   PROGOPTS = {
   { "/ENTRY:WinMain"; Config = { "win32--", "win64--" } },
   }
   to common Env
3. run tundra
4. /ENTRY:WinMain is not included in the linker options as expected

tundra -c and deleting all .tundra-* files is a workaround.

Currently something cryptic about type conversions in the C code is output for an error message. Should really say: "no such dir".

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.

Support Application and Framework bundle generation.

Tundra can already build foreign programs just fine, but a cross-compilation aware configuration is needed e.g. for consoles when compiling tools.

Example:

ExternalLib {
  Name = "directx",
  Propagate = {
    Libs = { { ... ; Config = "win32-*-*"  } },
    Includes = { ... },
  },
}

SharedLibrary {
  Name = "foo",,
  Depends = { "directx", ... }, -- automatically pull in dx libs/includes
} 

Tundra should have a way to dump all elements of the signing process in human-readable form to facilitate debugging of build issues.

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.

Relative to $(SolutionDir) is probably preferable, but absolute works fins too..

This is needed for byproduct files such as PDBs, .ext files etc.

Input signing currently is serialized on file access which is not ideal.

Tundra should automatically detect the number of core available and use that many threads.

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.

The current project generation isn't very good for C# projects, they need special care and pampering via custom MSBuild files so intellisense works.

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.

For small builds having a separate Units file might be overkill.

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.

Support storing stuff such as:

• CPU count
• Verbosity levels
• Named targets
• Toolsets

Essentially command line arguments into a config file. Provide a --config option similar to git that allows you to set/list these options.

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.

Tundra 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.

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 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.

The native code (especially engine.c) should be split up more clearly into various modules:

• Data collection (Lua interfacing code) - This code never has to worry about threading so it can be simpler and use various traditional tricks
• Native setup - Ancestor loading, saving etc
• Building - This code must always worry about correct locking

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.

Bootstrapping tundra on msvc2008 fails due to msvc-winsdk requires 2010 sdk.

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.

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.

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.

Here's what we could accelerate with the change journal:

• Globbing (Keep an database of files)
• Signing (Store content digest for each file in the database)

The drawbacks are:

• Change journal access requires administrator level privileges
• The change journal is global for the drive, so on busy drives (C:) there is a lot of irrelevant traffic to parse through

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.

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.

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.

repro:

rm -rf tundra-output
rm .tundra-*

tundra --ide-gen=msvc80

=> fail

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" } }

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).

Convenient to get code generators and tools to always build.

E.g. MacOSX ar doesn't like just updating the same archive over and over again.

• Add a new per-node option OverwriteOutputs that defaults to true
• If the option is false, delete the output files of the node before the action is run
• Add environment/extension option to somehow set this new node option on archive files

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.