-
Notifications
You must be signed in to change notification settings - Fork 204
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 builddependencies iterable. #2741
Make builddependencies iterable. #2741
Conversation
This is a list of list of buildependencies. It gets iterated on top of the common builddependencies. This will allow e.g. to build with multiple Python versions. A toy test is included. The "prepare" step is now fully iterated which needed a few adjustments. Hopefully this doesn't break anything.
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.
Some files could not be reviewed due to errors:
./easybuild/framework/easyconfig/easyconfig.py:201:-470: W605 invalid escape ...
./easybuild/framework/easyconfig/easyconfig.py:201:-470: W605 invalid escape sequence '\ ' ./easybuild/framework/easyconfig/easyconfig.py:201:-461: W605 invalid escape sequence '\ ' ./easybuild/framework/easyconfig/easyconfig.py:201:-346: W605 invalid escape sequence '\ ' ./easybuild/framework/easyconfig/easyconfig.py:201:-269: W605 invalid escape sequence '\ '
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.
Some files could not be reviewed due to errors:
./easybuild/framework/easyconfig/easyconfig.py:201:-470: W605 invalid escape ...
./easybuild/framework/easyconfig/easyconfig.py:201:-470: W605 invalid escape sequence '\ ' ./easybuild/framework/easyconfig/easyconfig.py:201:-461: W605 invalid escape sequence '\ ' ./easybuild/framework/easyconfig/easyconfig.py:201:-346: W605 invalid escape sequence '\ ' ./easybuild/framework/easyconfig/easyconfig.py:201:-269: W605 invalid escape sequence '\ '
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.
Some files could not be reviewed due to errors:
./easybuild/framework/easyconfig/easyconfig.py:201:-470: W605 invalid escape ...
./easybuild/framework/easyconfig/easyconfig.py:201:-470: W605 invalid escape sequence '\ ' ./easybuild/framework/easyconfig/easyconfig.py:201:-461: W605 invalid escape sequence '\ ' ./easybuild/framework/easyconfig/easyconfig.py:201:-346: W605 invalid escape sequence '\ ' ./easybuild/framework/easyconfig/easyconfig.py:201:-269: W605 invalid escape sequence '\ '
iterate_builddependencies is a list of lists of tuples unlike exts_list which is just a list of lists.
This way we make sure they are always considered.
This works but still needs a bit of cleanup:
|
At the EUM @boegel was asking about why not to extend
How do you deal with the common CMake builddependency? Parse it twice? Implement duplicate detection in the framework? |
I have now implemented proper module unloading. Hopefully it works fine with Tmod. Actually the way things are now it may not be to hard after all to iterate over builddependencies itself. |
Just in case, I've put a patch vs develop for builddependencies without the iterate_builddependencies here keyword here: I think it works well but the hiddendependencies code is getting rather cumbersome, so I'll work on a new PR to address that (I suppose we could set dep['hidden']=True instead of needing to remove them and then adding them back in the dump code). |
#2748 cleans up hiddendependencies. |
This reverts commit 3bf5873.
builddeps = self['builddependencies'] | ||
if 'builddependencies' in self.iterate_options and not isinstance(builddeps[0], dict): | ||
# flatten if not iterating yet | ||
builddeps = flatten(builddeps) |
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.
@bartoldeman During today's conf call you mentioned that one option could be to create two separate methods for this, to clearly discriminate the two situations, and avoid mixing them?
This allows (build)dependencies() be flattened strictly outside the iterating process.
@bartoldeman Problem with failing tests with Python 2.6 should be fixed with #2807, but seems like you broke something else as well. |
(close/re-open to trigger new Travis run now that #2807 is merged) |
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.
partially fixed with ComputeCanada#15
# take into account that this *dependencies parameter may be iterated over | ||
if key in self.iterate_options: | ||
deps = flatten(deps) | ||
deps_ref = flatten(deps_ref) |
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.
@bartoldeman This looks wrong to me... flatten
will create a new list, so deps_ref
is most definitely no longer a reference to the original list...
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.
Actually, it's OK. deps_ref
will be a new list, but the entries inside are still references to the original dependency dict
values that we aim to modify, so it's all good...
|
||
if key in parsed_ec.iterate_options: | ||
val = flatten(val) | ||
orig_val = flatten(orig_val) |
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.
@bartoldeman Same here, flatten
creates a new list, so this is no longer a reference to the original list...
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.
Same here, it's OK to use flatten
here, since we're still using references to the original dict
values, and that's what wer'e changing (not the list itself).
rename 'EasyBlock.reset_changes' to 'EasyBlock.reset_env' + use 'nub'
can't use nub to filter out duplicates in flattened list of build dep…
…ld take a (Python) programming class...)
fix filtering of duplicates in builddependencies method
Tested with modified
Works as intended, so I consider this good to go. Thanks you very much for your hard work on this @bartoldeman, I'm well aware that this was far from trivial... |
# create a list of all options that are actually going to be iterated over | ||
# builddependencies are always a list, need to look deeper down below | ||
self.iterate_options = [opt for opt in ITERATE_OPTIONS | ||
if opt != 'builddependencies' and isinstance(self[opt], (list, tuple))] |
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.
@bartoldeman I only realize now that this is done too early...
We're assuming here that once the easyconfig file is parsed, we know whether which easyconfig parameters are to be iterated over. That breaks backwards compatibility in some sense, since before this change we had the ability to tweak the easyconfig parameter values before they were actually being used...
And that's exactly what we're doing with FFTW
, where we define the list of configure options to iterate over in self.cfg['configopts']
via run_all_steps
...
That value is not picked up for defining self.iterate_options
, and hence stuff is broken.
I think we'll need to postpone this to avoid breaking backwards compatibility (yet still handle builddependencies
here)...
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.
problem should be fixed with #2810
This is a list of list of buildependencies. It gets iterated on top
of the common builddependencies. This will allow e.g. to build with
multiple Python versions. A toy test is included.
The "prepare" step is now fully iterated which needed a few adjustments.
Hopefully this doesn't break anything.