Standalone Exporter

vvvv gamma feature
1

Hi there,

this is a feature request for a standalone exporter*.

imagine the following scenario/workflow for your project:

  • you create a project with some patches, assets, custom libraries and all that jazz
  • ideally everything is organized in a nice repo
  • there’s several options once somebody pulled that repo:
    • open a vl patch to edit the project
    • use the exporter that just compiles the main patch to an exe as if you triggered the export from within vvvv

i’d love to have an exporter that has the following features:

  1. a gui like the current exporter gui + some more options like a file-chooser or the ability to set a custom package-reposiories directory.

  2. the exporter automatically restores nugets (maybe also a button in the gui).

  3. the tool has a commandline interface (like vvvv.exe has).
    vvvv-exporter.exe -o ./main.vl --package-repositories ./packages --outputdir ./Application/ --AndSoOn

  4. the exporter installs like vvvv with a setup.exe that installs msbuild so it can run on machines that have never seen vvvv before

*maybe it would be good enough (and much less work, i guess) to drop the whole gui stuff and just give vvvv.exe this ability?

what do you think?

6 Likes
2

yes to all of that :)

this would open the possibilities for a cloud-based builder that could somehow be triggered by Github actions and publish gh releases automagically :x

2 Likes
3

nice idea, that could indeed be a future commandline option:

vvvv.exe --build ./main.vl --package-repositories ./packages --outputdir ./Application/ --AndSoOn

but then the question of relative file paths remains, how would you handle assets in that case? do they need to be in the right folder already and the newly created exe knows where to look?

4

Well, the relative filepath issue is a separate thing that also affects exports from within vvvv, right? So, this one needs to be tackled anyhow I guess.

One could at least make a script that moves files around and builds.

5

indeed, a script to move files if needed is a good idea!

6

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.

8

Just opened up a similar request, which is a copy of this thread more or less.

I will back up all the thoughts here by @sebl and @sebescudie and just add the following that should be pretty simple to implement

Why do I have to open a patch to export it? why can’t I just go to the exporter and select a patch to export? If the patch is very demanding, it will affect the export time. and I can already close the patch using ctrl+w when having started the exporter.

Also a more fine control of what to include. Such as the complete cs project? it could be an option to keep it. I guess it is not really useful unless you want to do some debugging elsewhere.

Sune

9

Also having some way of choosing what to include. As a project evolves there might be stuff leftover, such as stuff that start with Skia and then moves to Stride.

So if it would be possible to see that dependecies are actually being used. It might already happen in the background, I don’t know.

10

could this be utilized? https://github.com/xoofx/dotnet-releaser

1 Like