Hi,

I would like to add Rust support to tundra but I'm not sure how to go about it. Just adding support for compiling rust files as is very easy as it's just a regular compiler.

The thing is that Rust has it's own build/package manager called Cargo and some info can be found about it here: http://doc.crates.io/guide.html

The way it works is that you set up a project according to some rules and allows you to depend on packages that can be downloaded when you build and such which is very convenient.

The best way I see it would be if it would be possible to start "cargo build" for a given rust project within tundra and have tundra then link with the output in the cargo output folder (in cargo's case it ends up like target/debug/foo)

Reading the FAQ on cargo it also states this:

Can Cargo be used inside of make (or ninja, or ...)

Indeed. While we intend Cargo to be useful as a standalone way to compile Rust projects at the top-level, we know that some people will want to invoke Cargo from other build tools.

We have designed Cargo to work well in those contexts, paying attention to things like error codes and machine-readable output modes. We still have some work to do on those fronts, but using Cargo in the context of conventional scripts is something we designed for from the beginning and will continue to prioritize.

http://doc.crates.io/faq.html

So I feel it should be possible to allow a nice integration into Tundra but I'm unsure of how to do it.

I get a fair deal of this warnings, they never really seem to make a difference but they do make me wonder, is tundra cleaning up these temp files faster than the linker manage to access them or what's going on? I tried accessing the files post-build but the file did not exist. I'm a bit lost as to how approach this problem but I wanted to put up an issue about it. I'll add more info about this as I find out more about the issue.

LINK : fatal error LNK1104: cannot open file `C:\Users\...\AppData\Local\Temp\tunFF72.tmp`

Hey,

In order to make it easier for tundra to be adopted, I'd like to investigate the possibility of relicensing tundra under the MIT license, so that people writing other frontends for tundra do not have to worry about the GPL requirements travelling to the frontend code.

I've talked with @deplinenoise about it, and he supports the idea if I do the legwork of chasing down all contributors.

This issue does that. My question to all people that have landed a PR into the tundra repo: Would you be willing to license the code you've contributed under the MIT license, so that we can make the entire repo MIT. I hope you will, tundra is an amazing build system and I'd love to be able to use it everywhere. If you do, simply replying on this issue with "I license all my contributions in the tundra repository under the MIT license" would suffice.

Thanks, Lucas

@leidegre @jsvennevid @jonaskje @jwtowner @uucidl @rudkx @emoon @bmharper @greatwolf @teddemunnik @mattrudder @Patuti @twoscomplement @aras-p

So I opted to use the vswhere tool to locate various VS 2017 installations that match certain criterias (i.e. has Visual C++ tooling). However, I've made it optional, if you specify an installation path manually it will use that instead. I found documentation regarding the usage of vswhere and have included it here.

This is incomplete but I wanted feedback from @deplinenoise or @kayru whether you think the direction is fine.

Also, trying to get rid of as much cruft as possible this time. Again, this is incomplete but it gets the compiler running.

When running tundra from the command line, the following text is printed:

couldn't resolve symbol InitializeConditionVariable in kernel32.dll; your windows version is not supported

Perhaps I'm just overlooking something, but how do change an ExternalLibrary that dynamically links against a .dylib (OS X) to to something that statically links agains the corresponding .a file of the same library?

I did some benchmarks on various build systems, Tundra included, and I'd thought I'd share my findings.

The generated build scripts used for testing are based off Noel's Llopis' famous build scripts here.

The environment used for testing is Win7 with an intel Q6600 quad core. Tundra 94d61aba71 built with mingw was used with optimizations enabled. Timing is measured in seconds. All build systems were performed using -j 6 parallel builds . The parameters used for script generation are: generate_libs.py root 50 100 20 5

            full build      incremental no-op   clean
bam         100.334         0.595               1.826
jam         120.955         1.275               0.288
lake        106.891         63.835              47.018
make        83.382          2.652               3.276
make-dep    102.787         20.911              17.035
ninja       79.248          0.686               1.575
scons       139.074         38.641              30.825
tundra      114.051         1.466               37.83 (*1.606)
waf         88.124          3.088               1.638

*ran with quiet(silent) option

A full rebuild using tundra isn't as fast as I thought but the incremental rebuild is pretty fast. The clean operation is interesting. When used without the quiet option, clean takes 37 seconds to complete. But when ran with the silent switch where nothing gets printed, it completes in under 2 seconds.

Note a lot of the build systems doesn't perform proper dependency checking with headers. Of the above only the following does: tundra, waf, ninja, make-dep.

mingw32-make version 3.82.90 with parallel job support under windows was used. Note that make is done without header dep checking while make-dep has proper header dependency -- the same tool is used in both cases. It's interesting how gnu make slows down a lot when header dependency comes into the picture. I suspect file io might be the culprit.

The bench scripts + modifications I've used can be found here.

Thoughts and comments?

If you use relative pathes in tundra.lua it's easy to end up in situation when absolute path to obj file is longer than 260 characters. In this case tundra doesn't complain until linker stage, when linking fails because linker cannot access that object file.

I can't find obvious workaround for this ... it's probably override function that generate path to obj files.

When building inside Visual Studio 2012 with tundra2, the IDE does not add warnings and errors to its "Error List" tab. The IDE manages to comprehend the output messages to some degree, since one can navigate the "Output" tab using Prev/Next buttons, but these items don't end up in the Error List tab. I have made sure that my Error List is not filtered at all.

I'm busy trying to figure out what could cause this. So far the only significant difference I can see is that tundra2 emits the full source file path in the build output, whereas tundra1 emits only the relative path.

There's VS2012 projects and a simple Makefile for the building.

But how to make an installable package now that Lua files are not embedded and there are other executables that need to be installed as well?

Might need a make install option that does mostly the right thing on Unix, and some sort of MSI builder for Windows.

Hi, sorry to open an issue for my question.

I have a library (with example programs) and build a standalone-version with tundra.lua and units.lua which compiles the lib and the examples in a directory. now I want to include the same repository, but as a subproject in a subfolder and include the units.lua in another tundra.lua, how can this be setup to be able to compile with the different base-directories?

to get the idea, I have for the standalone-lib this structure: ~/sources/libA/tundra.lua <- this uses the units.lua in the same directory units.lua <- here all examples and the lib are references

and another project: ~/sources/prgX/external_libs/libA/tundra.lua <- this one is not used in the project itself units.lua tundra.lua <- includes units.lua AND external_libs/libA/units.lua units.lua <- project-sources

the question is: how can I set the basepath for the libA/units.lua, by setting somehow the sourcedir? (I could split the units.lua from the lib to include only the lib itself into the units.lua and let's say example.lua with the test-programs of the lib to separate the lib from the test-programs, but I still have the issue with the base-path). I could think of some way with a environment-variable you have to set as a build-base-path, but is there a better solution?

and another (hopefully simple) question: often I have to repeat stuff like this: Env = { CPPPATH = { "include", "examples/common", .... } }, Propagate = { Env = { CPPPATH = { "include", "examples/common",

so the propagated stuff is the same like the stuff for the lib/program itself, can this be somehow handled to write it only one time?

for both questions here is the units.lua from the lib: https://github.com/questor/bgfx/blob/master/units.lua

thanks!

When adding a DefRule to my Sources list, precompiled headers seem to be created N times for each Variant declared, resulting in the same file being the output target and failing to build.

The following tundra.lua demonstrates this using the latest v2.08 build:

Build {
    Units = function()
        DefRule {
            Name = "ExampleGenerator",
            Pass = "ExamplePass",
            Command = "echo Building $(<) $(@) > $(@)",
            ConfigInvariant = false,
            Blueprint = {
                Source = {Required = true, Type = "string", Help = "Input filename"},
                OutName = {Required = true, Type = "string", Help = "Output filename"}
            },
            Setup = function(env, data)
                return {
                    InputFiles = {data.Source},
                    OutputFiles = {"$(OBJECTDIR)/_generated/" .. data.OutName}
                }
            end
        }

        local App = Program
        {
            Name = "App",
            PrecompiledHeader = {
                Source = "stdafx.cpp",
                Header = "stdafx.h",
                Pass = "PchGen"
            },
            Sources = {
                ExampleGenerator {
                    Source = "example.txt",
                    OutName = "example.h"
                }
            }
        }

        Default(App)
    end,

    Passes = {
        ExamplePass = {Name = "Example Pass", BuildOrder = 1},
        PchGen = {Name = "Precompiled Header Generation", BuildOrder = 2}
    },

    Configs = {
        Config {
            Name = "win32-msvc",
            SupportedHosts = {"windows"},
            DefaultOnHost = "windows",
            Tools = {
                {"msvc-vs2017", TargetArch = "x86"}
            }
        }
    },

    Variants = {"debug", "release", "production"}
}

Logging the source_files var from x_source_list shows this clearly:

Generating DAG for win32-msvc-release-default
Source list
{
  [1] =     {
      DagCache= <nested table>
      __index= <nested table>
      Decl= <nested table>
    },
  [2] = "stdafx.cpp",
}
Generating DAG for win32-msvc-debug-default
Source list
{
  [1] =     {
      DagCache= <nested table>
      __index= <nested table>
      Decl= <nested table>
    },
  [2] = "stdafx.cpp",
  [3] = "stdafx.cpp",
}
Generating DAG for win32-msvc-production-default
Source list
{
  [1] =     {
      DagCache= <nested table>
      __index= <nested table>
      Decl= <nested table>
    },
  [2] = "stdafx.cpp",
  [3] = "stdafx.cpp",
  [4] = "stdafx.cpp",
}
save_dag_data: 3 bindings, 26 accessed files

When CreateProcess() returns 0, the correct error value should be shown using GetLastError() instead of errno. errno is only c runtime and this is a WinApi function.

This is pretty common:

label:  incbin "somefile"

Unfortunately Tundra's generic header scanner doesn't support this because it bails out as soon as it sees the label part.

When trying to use the documentation on Unit Script Template to create my own Unit Type, it seems to fail to use the code provided.

My definition:

module("my_compiler", package.seeall)
local nodegen = require "tundra.nodegen"
local _mt = nodegen.create_eval_subclass {}
local blueprint = {
    Sources = {
        Type = "source_list",
        Help = "List of sources",
        Required = true,
        ExtensionKey = "MY_EXTENSION",
    },
    Name = {
        Type = "string",
        Required = true,
    },
}

function _mt:create_dag(env, data, deps)
    return env:make_node {
        Label = "MyCompiler $(@)",
        Action = "echo", --"$(MYACTION)",
        Inputs = data.Sources,
        Outputs = {},
        Dependencies = deps,
    }
end

nodegen.add_evaluator("MyCompiler", _mt, blueprint)

But when trying to run MyCompiler then I get that when trying to create the dag, it calls the :create_dag-function where the make_node function doesn't exist.

(attempt to call method 'make_node' (a nil value))

It would be really awesome if there would be an example of how to get this working in the examples/directory

When using the install syntax extension I get an error message (it seems like it was not updated when an API breaking change was done before.). I am trying to use this feature for copying DLL's of third party dependencies into the output directory. Does anyone have a workaround for this?

...ed\Documents\projects\tundra\scripts\tundra\boot.lua:23: Sources: source_list must provide ExtensionKey
stack traceback:
        [C]: in function 'error'
        ...ed\Documents\projects\tundra\scripts\tundra\boot.lua:23: in function 'errorf'
        ...Documents\projects\tundra\scripts\tundra\nodegen.lua:686: in function 'add_evaluator'
        ...ts\projects\tundra\scripts\tundra\syntax\install.lua:40: in main chunk
        [C]: in function 'require'
        [string "tundra.lua"]:2: in main chunk
        [C]: in function 'xpcall'
        ...cuments\projects\tundra\scripts\tundra\buildfile.lua:242: in function 'run'
        ...ed\Documents\projects\tundra\scripts\tundra\boot.lua:93: in function 'generate_dag_data'
        ...ers\Ted\Documents\projects\tundra\scripts\tundra.lua:8: in function 'action'
        ...ers\Ted\Documents\projects\tundra\scripts\tundra.lua:38: in function <...ers\Ted\Documents\projects\tundra\scripts\tundra.lua:22>
        (tail call): ?