search

craftr-build / craftr-build-4.x

Frontend for the Craftr build framework.
https://craftr-build.github.io/craftr/
Other
60 stars 14 forks source link

build.ninja re-export #174

Open mcquay239 opened 7 years ago

mcquay239 commented 7 years ago

Hi Niklas!

You put Craftr_run_command to build.ninja but you don't generate rule and build for it. Is it implemented or planned?

NiklasRosenstein commented 7 years ago

Hi Anton! Craftr_run_command is currently used for "tasks", which is when a generated rule actually needs to execute a Python function in your Craftrfile. Automatically re-exporting is currently not planned, I'm happy to recognize this as a feature request, though.

I'm not sure how to best approach determining whether a re-export is necessary. Probably take all Craftrfiles into account and re-export when any of them changed. Do you think that would be sufficient?

I wonder, do you use the craftr build command or do you run ninja directly in the build directory? The way it is intended is to use craftr build. This command would take over checking if a re-export is necessary. Actually, currently it will already tell you that a re-export might be necessary, but does not actually perform it.

Thanks for the input!

Unfortunately, Craftr development is a bit on halt at the moment because I'm busy with work. 😞

mcquay239 commented 7 years ago

The depending Craftrfiles set is a good first approach for me. But isn't it easier to get the whole python modules graph? Of course it won't be 100% reliable because it's impossible to track the real deps (like shell.exec('some external tool') but the external python imports will be tracked.

Calling ninja directly is preferrable for me because of the shell autocompletion and additional flags (like dry-run, custom targets and so on).

Thank you, Niklas!