-
Notifications
You must be signed in to change notification settings - Fork 13
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
Make builddir a runtime argument of FileWriteTransformation
#425
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #425 +/- ##
==========================================
+ Coverage 93.04% 93.07% +0.02%
==========================================
Files 198 198
Lines 39320 39422 +102
==========================================
+ Hits 36587 36691 +104
+ Misses 2733 2731 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Documentation for this branch can be viewed at https://sites.ecmwf.int/docs/loki/425/index.html |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All in all this looks good. I've left one conceptual question for @reuterbal , but once answered this is GTG for me.
@@ -495,7 +498,7 @@ def _get_definition_items(_item, sgraph_items): | |||
_item.scope_ir, role=_item.role, mode=_item.mode, | |||
item=_item, targets=_item.targets, items=_get_definition_items(_item, sgraph_items), | |||
successors=graph.successors(_item, item_filter=item_filter), | |||
depths=graph.depths | |||
depths=graph.depths, build_args=self.build_args |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[no action] I would argue that we could also attach the build_args
to the Item
, so that we continue to use the Item
as the universal meta-data object that gets handed from Scheduler
to Transformation
? Admittedly, this can be said for almost any of the arguments here - so this might also be part of a larger "scheduler-item" refactoring and need not go into this PR.
Any strong opinions on this, @reuterbal ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good idea.
The only thing where we need to be a little careful is that the definitions
part is updated dynamically when calling _parse_items
. When re-parsing due to topology changes that introduce a new dependency that was previously not part of the graph, these definitions would then be missing for existing items. Hence, this is probably out of scope for this PR.
For the other arguments it depends. role
and targets
should be used from the Item and have only been kept for backwards compatibility. We should indeed remove them here. The other two are properties at a graph-level, not an item level, so there's an argument to keep them separate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, agreed. I'll look into this in a separate PR. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looks great. A few nit-picks on nomenclature but otherwise good to go!
loki/batch/scheduler.py
Outdated
""" | ||
|
||
# TODO: Should be user-definable! | ||
source_suffixes = ['.f90', '.F90', '.f', '.F'] | ||
|
||
def __init__(self, paths, config=None, seed_routines=None, preprocess=False, | ||
includes=None, defines=None, definitions=None, xmods=None, | ||
omni_includes=None, full_parse=True, frontend=FP): | ||
omni_includes=None, full_parse=True, frontend=FP, builddir=None): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest we use a more generic term than builddir
here, for example output_path
. There is no reason that this needs to be an actual build directory, and for Loki processing that is not integrated with a build the name wouldn't make much sense.
It's just that in our use case we happen to specify the build directory as the output path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about output_dir
? Since the full path of the file is constructed combining this and sourcepath, I think we should keep dir in the name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good point! The paths
argument suffer from the same misnomer but that's a separate issue
@@ -495,7 +498,7 @@ def _get_definition_items(_item, sgraph_items): | |||
_item.scope_ir, role=_item.role, mode=_item.mode, | |||
item=_item, targets=_item.targets, items=_get_definition_items(_item, sgraph_items), | |||
successors=graph.successors(_item, item_filter=item_filter), | |||
depths=graph.depths | |||
depths=graph.depths, build_args=self.build_args |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good idea.
The only thing where we need to be a little careful is that the definitions
part is updated dynamically when calling _parse_items
. When re-parsing due to topology changes that introduce a new dependency that was previously not part of the graph, these definitions would then be missing for existing items. Hence, this is probably out of scope for this PR.
For the other arguments it depends. role
and targets
should be used from the Item and have only been kept for backwards compatibility. We should indeed remove them here. The other two are properties at a graph-level, not an item level, so there's an argument to keep them separate.
@@ -72,6 +69,6 @@ def transform_file(self, sourcefile, **kwargs): | |||
path = Path(item.path) | |||
suffix = self.suffix if self.suffix else path.suffix | |||
sourcepath = Path(item.path).with_suffix(f'.{self.mode}{suffix}') | |||
if self.builddir is not None: | |||
sourcepath = self.builddir/sourcepath.name | |||
if (builddir := kwargs.get('build_args', {}).get('builddir', None)) is not None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we're be able to afford two lines to make this a little more readable :)
if (builddir := kwargs.get('build_args', {}).get('builddir', None)) is not None: | |
build_args = kwargs.get('build_args') | |
if build_args and (builddir := build_args.get('builddir')): |
@@ -428,8 +428,8 @@ def test_transformation_file_write(tmp_path): | |||
ricks_path = tmp_path/'rick.roll.java' | |||
if ricks_path.exists(): | |||
ricks_path.unlink() | |||
FileWriteTransformation(mode='roll', suffix='.java').apply(source=source, item=item, | |||
build_args={'output_dir': tmp_path}) | |||
FileWriteTransformation(suffix='.java').apply(source=source, item=item, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[no action!] The suffix should probably become an item property as well in the future, particularly when thinking of transpilation use cases?
067ec82
to
74d9660
Compare
A small PR that turns the builddir into a runtime argument of the
FileWriteTransformation
. This allows the builddir to be passed in via command line arguments even if theFileWriteTransformation
is being overridden via a scheduler config.