Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tundra.syntax.install broken #248

Open
teddemunnik opened this issue Apr 6, 2015 · 3 comments
Open

tundra.syntax.install broken #248

teddemunnik opened this issue Apr 6, 2015 · 3 comments

Comments

@teddemunnik
Copy link
Contributor

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): ?
@deplinenoise
Copy link
Owner

You're right this is broken. The problem the extension key stuff is solving is that of filtering out unwanted input files by only picking up certain extensions. For example the C++ unit types use this to only pick up .cpp, .h and similar files and not every random file produced by subtargets like .pdb. In this case maybe the copy builder does want everything. I'm not sure how to best convey that, but it sounds like it will need a code patch. A hack might be to create a env variable EVERY_FILE = { "" } and then specify ExtensionKey="EVERY_FILE" in the install rule. That could work if the rest of the code accepts an empty string as matching every "extension".

@teddemunnik
Copy link
Contributor Author

I was looking at this again today and I made a patch that removes the need for ExtensionKey ( accepts all suffixes when ExtensionKey is nil ).
teddemunnik/tundra@f19b52f

However it looks like there are some API changes that the install syntax was not updated for, which I currently do not have enough understanding of to attempt to fix:

  • There is no way to give the Install node a name, but the code expects a name parameter. This possibly also causes a duplicate guid error on building.
  • files.copy_file no longer exists.

Is there another way to copy DLL's into the target directory that I'm missing, which supports separate input paths for 32 and 64 bit builds?

@deplinenoise
Copy link
Owner

OK; that's going to require a bit more fixup.

If the DLLs are built with Tundra you can override Target on them to redirect where they go. If not, you'll need something like CopyFile - you might have more luck with that than Install, the latter probably hasn't been used since after the API changes which is why it's broken. CopyFile has an example (I just tested it) so that seems workable: examples/filecopy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants