Skip to content
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

Compiler wrappers don't add "pkg.headers.directories" to the include list #10604

Conversation

alalazo
Copy link
Member

@alalazo alalazo commented Feb 14, 2019

fixes #10601
fixes #10603

Due to a bug this attribute is wrong for packages that use directories as namespaces. For instance it will add <boost-prefix>/include/boost instead of <boost-prefix>/include to the include path.

As a minor addition a few loops in the compiler wrappers have been simplified.

fixes spack#10601

Due to a bug this attribute is wrong for packages that use directories
as namespaces. For instance it will add "<boost-prefix>/include/boost"
instead of "<boost-prefix>/include" to the include path.

As a minor addition a few loops in the compiler wrappers have been
simplified.
@alalazo
Copy link
Member Author

alalazo commented Feb 14, 2019

@davydden With this I'm able again to build cmake:

$ spack install -j 2 cmake
[...]
==> Successfully installed cmake
  Fetch: 0.05s.  Build: 8m 43.00s.  Total: 8m 43.05s.
[+] /home/mculpo/PycharmProjects/spack/opt/spack/linux-ubuntu18.04-x86_64/gcc-8.2.0/cmake-3.13.4-fehljuzg2ydcsq2tyq2jonztuxds2usn

can you double check if it solves also your issue?

Also pinging @jabl and @HadrienG2 as their build errors might be related to this.

@davydden
Copy link
Member

<boost-prefix>/include/boost instead of <boost-prefix>/include

perhaps we can make boost return a dummy HeaderLIst(/prefix/include/dummy.h) so that it adds include instead of include/boost?

@alalazo
Copy link
Member Author

alalazo commented Feb 14, 2019

perhaps we can make boost return a dummy HeaderLIst(/prefix/include/dummy.h) so that it adds include instead of include/boost?

@davydden I think this needs to be addressed in a cleaner way as it involves quite a few packages. I vaguely remember there was an issue open for that, but can't find it anymore. In the worst case I'll open a new one soon.

@davydden
Copy link
Member

@alalazo

I think this needs to be addressed in a cleaner way as it involves quite a few packages.

fair enough.

Copy link
Member

@tgamblin tgamblin left a comment

Choose a reason for hiding this comment

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

I'm going to merge this as a hotfix for now, but @scheibelp should investigate how to reconcile it with #8136.

@tgamblin tgamblin merged commit 1ec0d4f into spack:develop Feb 14, 2019
@alalazo alalazo deleted the fixes/wrong_include_paths_passed_to_wrapper branch February 14, 2019 18:48
@alalazo
Copy link
Member Author

alalazo commented Feb 14, 2019

@tgamblin Time permitting, I'll have a look tomorrow at HeaderList. There are chances that we only need a slight change or an override to the default implementation of HeaderList.directories.

scheibelp pushed a commit that referenced this pull request Feb 26, 2019
This restores the use of Package.headers when computing -I options
for building a package that was added in #8136 and reverted in
#10604. #8136 used utility logic that located all header files in
an installation prefix, and calculated the -I options as the
immediate roots containing those header files.

In some cases, for a package containing a directory structure like

  prefix/
    include/
	  ex1.h
	  subdir/
	    ex2.h

dependents may expect to include ex2.h relative to 'include', and
adding 'prefix/include/subdir' as a -I was causing errors,
in particular if ex2.h has the same name as a system header.

This updates header utility logic to by default return the base
"include" directory when it exists, rather than subdirectories.
It also makes it possible for package implementers to override
Package.headers to return the subdirectory when it is required
(for example with libxml2).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working compilers hotfix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Installation issue: expat (but the root cause is likely libbsd-related) broken compiler wrappers?
3 participants