Skip to content

LIBXSMM 1.8.2#6896

Merged
adamjstewart merged 37 commits intospack:developfrom
hfp:develop
Jan 21, 2018
Merged

LIBXSMM 1.8.2#6896
adamjstewart merged 37 commits intospack:developfrom
hfp:develop

Conversation

@hfp
Copy link
Copy Markdown
Contributor

@hfp hfp commented Jan 11, 2018

Introduces LIBXSMM 1.8.2 (release notes: https://github.com/hfp/libxsmm/releases/tag/1.8.2).

Package adjustments: use join_path instead of hard-coding the separator. Install "version.txt" into the documentation directory (doc). Removed installing "README.md" (from LIBXSMM's root directory) as it overrides the README.md already provided in the documentation folder. The latter uses the correct relative references to the other parts of the documentation.

Note: Apparently, "FC=/path/to/gfortran spack install libxsmm" is currently needed for Spack since does not pick-up the Fortran compiler (but incorrectly uses the C compiler instead).

hfp added 25 commits March 31, 2017 11:45
…"version.txt" into the documentation directory. Removed installing "README.md" from LIBXSMM's root directory as it overrides README.md provided there. The latter uses correct relative references to the other documentation parts.

Note: Apparently, "FC=/path/to/gfortran spack install libxsmm" is currently needed for Spack since does not pick-up the Fortran compiler (but incorrectly uses the C compiler instead).
Copy link
Copy Markdown
Member

@adamjstewart adamjstewart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: Apparently, "FC=/path/to/gfortran spack install libxsmm" is currently needed for Spack since does not pick-up the Fortran compiler (but incorrectly uses the C compiler instead).

Have you tried editing patch to explicitly point to Spack's compiler wrappers? You can use spack_cc or env['CC'] to do this (similarly named things for cxx, f77, and fc defined in lib/spack/spack/build_environment.py).

install('LICENSE.md', doc_path)

def install(self, spec, prefix):
if '+header-only' in spec and '@1.6.2:' not in spec:
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could probably be converted to a conflicts() directive if you want.

@@ -32,10 +32,11 @@ class Libxsmm(Package):
and small convolutions.'''
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This package should probably be converted to a MakefilePackage. Then install would become build, manual_install would become install, and patch would become edit.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have addressed your recommendation in the updated PR.

install('README.md', doc_path)
install('LICENSE', doc_path)
install('version.txt', doc_path)
install('LICENSE.md', doc_path)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't that break installation of old version?

Copy link
Copy Markdown
Contributor Author

@hfp hfp Jan 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I addressed this issue in the updated PR.


def manual_install(self, prefix):
def install(self, spec, prefix):
spec = self.spec
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can delete this line now

if '~header-only' in spec:
install_tree('lib', prefix.lib)
doc_path = prefix.share + '/libxsmm/doc'
doc_path = join_path(prefix.share, 'libxsmm', 'doc')
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use prefix.libxsmm.doc instead of join_path(...)

install('LICENSE', doc_path)
install('version.txt', doc_path)

def build(self, spec, prefix):
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you move this above install to keep things in order? Also, can you convert the below InstallError to a conflict?

@hfp
Copy link
Copy Markdown
Contributor Author

hfp commented Jan 20, 2018

Have you tried editing patch to explicitly point to Spack's compiler wrappers? You can use spack_cc or env['CC'] to do this (similarly named things for cxx, f77, and fc defined in lib/spack/spack/build_environment.py).

Hello Adam, thank you for educating Spack to me, and your patience with this PR!

Regarding the FC issue, it seems to be deeper (inside of Spack, and beyond my scope). I believe the "edit" stage can be entirely removed from the LIBXSMM package specification. An edit stage sounds anyways like my project is broken or would require some patch. LIBXSMM's make takes the CC, FC, and CXX variables (when present), and this can be used to inject Spack's spack_cc, etc. However, the default configuration of Spack (e.g., a checkout of the develop-branch "as is") does not pick-up the platform's default Fortran compiler. Instead, Spack's default seems to be that spack_fc points to gcc, which will obviously fail to compile Fortran code.

variant('header-only', default=False,
description='Produce header-only installation')
# variant +header-only is only available since v1.6.2
conflicts('+header-only', when='@:1.6.2')
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

conflicts actually has an optional msg attribute that you can set to this comment if you want.

@adamjstewart
Copy link
Copy Markdown
Member

However, the default configuration of Spack (e.g., a checkout of the develop-branch "as is") does not pick-up the platform's default Fortran compiler. Instead, Spack's default seems to be that spack_fc points to gcc, which will obviously fail to compile Fortran code.

Can you tell me more about this? That definitely shouldn't be the case. If you delete your compilers.yaml and run spack compiler find, what does it pick up?

P.S. If you're curious how our autodetection works, you can check out lib/spack/spack/compilers/gcc.py.

@hfp
Copy link
Copy Markdown
Contributor Author

hfp commented Jan 21, 2018

Can you tell me more about this? That definitely shouldn't be the case. If you delete your compilers.yaml and run spack compiler find, what does it pick up?
P.S. If you're curious how our autodetection works, you can check out lib/spack/spack/compilers/gcc.py

Ok, I ran the auto-detection and $HOME/.spack/linux/compilers.yaml contained the source'd Intel Compiler, some older/extra GCC versions that I need from time to time, and it also found the default compiler -- except the default Fortran compiler. The default/platform compiler (Ubuntu 17.10) is 7.2. So it looks like the detection does not like GFortran 7.2. Though -dumpversion and -dumpfullversion are both supported. As noted earlier, I simply checked out spack (develop branch). If you like, I can contact you and send you a login for the system, where you can try reproducing this.

@adamjstewart
Copy link
Copy Markdown
Member

A login for your system would definitely help. Things I would like to look at:

  1. What are the executable names? Are they gcc and gfortran, or something more complicated with suffixes? Does one have suffixes but not the other? Are they installed in the same directory?
  2. What is the output of gcc -dumpversion, gcc -dumpfullversion, gfortran -dumpversion, and gfortran -dumpfullversion?

@adamjstewart adamjstewart merged commit 202c413 into spack:develop Jan 21, 2018
@adamjstewart
Copy link
Copy Markdown
Member

P.S. Feel free to open a new issue to track this discussion. That will probably get more attention than a side comment on a PR.

ch741 pushed a commit to ch741/spack that referenced this pull request Apr 20, 2018
* Included LIBXSMM 1.8 into the list of available versions.

* LIBXSMM 1.8.1

* LIBXSMM 1.8.2 (release notes: https://github.com/hfp/libxsmm/releases/tag/1.8.2).

* LIBXSMM: Use join_path instead of hard-coding the separator. Install "version.txt" into the documentation directory. Removed installing "README.md" from LIBXSMM's root directory as it overrides README.md provided there. The latter uses correct relative references to the other documentation parts.

Note: Apparently, "FC=/path/to/gfortran spack install libxsmm" is currently needed for Spack since does not pick-up the Fortran compiler (but incorrectly uses the C compiler instead).

* LIBXSMM: converted Package into MakefilePackage (to address spack#6896 (comment)).

* LIBXSMM: account for changed file set in 1.8.2 onward (addresses spack#6896 (review)).

* Fixed incorrect behavior of "+header-only", which did not install the "src" folder. Addressed spack#6896 (comment) and spack#6896 (comment).

* Use conflicts msg argument to present a friendly error message.
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

Successfully merging this pull request may close these issues.

3 participants