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.

Sign up for GitHub

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

Jump to bottom

Header path for default source build and Debian should match #786

Closed
jedbrown opened this issue Nov 6, 2023 · 6 comments
Closed

Header path for default source build and Debian should match #786

jedbrown opened this issue Nov 6, 2023 · 6 comments

Comments

@jedbrown
Copy link
Contributor

jedbrown commented Nov 6, 2023

A default source build installs $incdir/blis/blis.h, suggesting that a user should #include <blis/blis.h>.

Debian installs /usr/include/x86_64-linux-gnu/blis.h, which works with #include <blis.h>. (This path is actually a symlink through the /etc/alternatives system, but that aspect does not concern us here.)

Upstream should decide (and convey to users) which schema is intended. @devinamatthews and @fgvanzee have indicated in Discord that #include <blis.h> is preferred, meaning that the default make install should be changed. Although symlinks blis.h -> blis/blis.h are problematic on Windows, the outer header could be a simple stub with #include "blis/blis.h".
@jedbrown
Copy link
Contributor Author

jedbrown commented Nov 7, 2023

With 1.0 coming up, this should be resolved and documented prior to release.

@fgvanzee
Copy link
Member

fgvanzee commented Nov 7, 2023 •
edited
Loading

Thanks @jedbrown. Devin and I discussed this and we both agree that our preferred solution is to install a supplemental one-line blis.h header to the INCDIR install prefix (which is PREFIX/include by default, where PREFIX is the install prefix) that contains:

#include <blis/blis.h>

FYI: @cdluminate

EDIT: I think I meant "blis/blis.h"

@fgvanzee
Copy link
Member

fgvanzee commented Nov 9, 2023

FYI, I'm working on a PR for this issue.

@cdluminate
Copy link
Contributor

I will change the alternatives symlink installation path to synchronize with you.

fgvanzee added a commit that referenced this issue Nov 11, 2023
@fgvanzee
Install helper headers to INCDIR prefix.
09ce0fc 
Details:
- Install one-line headers to INCDIR whose entire purpose is to
  #include the actual headers within the local 'blis' header directory
  so that applications can #include "blis.h" instead of #include
  "blis/blis.h" (and/or "cblas.h" instead of "blis/cblas.h" if CBLAS is
  enabled) when headers are installed to global paths. (Note that
  INCDIR is the installation prefix for headers as specified by
  '--includedir=INCDIR', which defaults to 'PREFIX/include' if not
  specified.) Not sure how this problem went unreported for so long,
  since presumably any user trying to #include "blis.h" from a global
  installation would have encountered a compiler error.
- The one-line blis.h and cblas.h headers now reside in the 'build'
  directory, ready to install as is.
- Thanks to to Jed Brown for reporting this via Issue #786, and for
  Devin Matthews and Mo Zhou for their engagement.
- Harmonized the rule in the top-level Makefile for installing blis.pc
  into SHAREDIR/pkgconfig with conventions for others vis-a-vis
  verbosity/non-verbosity.
@fgvanzee fgvanzee mentioned this issue Nov 11, 2023
Merged
fgvanzee added a commit that referenced this issue Nov 21, 2023
@fgvanzee
Install helper headers to INCDIR prefix. (#787)
141a6c9 
Details:
- Install one-line headers to INCDIR whose entire purpose is to
  #include the actual headers within the local 'blis' header directory
  so that applications can #include "blis.h" instead of #include
  <blis/blis.h> (and/or "cblas.h" instead of <blis/cblas.h> if CBLAS is
  enabled) when headers are installed to global paths. (Note that
  INCDIR is the installation prefix for headers as specified by
  '--includedir=INCDIR', which defaults to 'PREFIX/include' if not
  specified.) Not sure how this problem went unreported for so long,
  since presumably any user trying to #include "blis.h" from a global
  installation would have encountered a compiler error.
- The one-line blis.h and cblas.h headers now reside in the 'build'
  directory, ready to install as is.
- Thanks to to Jed Brown for reporting this via Issue #786, and for
  Devin Matthews and Mo Zhou for their engagement.
- Harmonized the rule in the top-level Makefile for installing blis.pc
  into SHAREDIR/pkgconfig with conventions for others vis-a-vis
  verbosity/non-verbosity.
@fgvanzee
Copy link
Member

@jedbrown I think this issue is resolved now. Let me know if there's anything left/else to discuss. Thanks for your feedback!

fgvanzee added a commit that referenced this issue Dec 12, 2023
@fgvanzee
Install helper headers to INCDIR prefix. (#787)
8109d18 
Details:
- Install one-line headers to INCDIR whose entire purpose is to
  #include the actual headers within the local 'blis' header directory
  so that applications can #include "blis.h" instead of #include
  <blis/blis.h> (and/or "cblas.h" instead of <blis/cblas.h> if CBLAS is
  enabled) when headers are installed to global paths. (Note that
  INCDIR is the installation prefix for headers as specified by
  '--includedir=INCDIR', which defaults to 'PREFIX/include' if not
  specified.) Not sure how this problem went unreported for so long,
  since presumably any user trying to #include "blis.h" from a global
  installation would have encountered a compiler error.
- The one-line blis.h and cblas.h headers now reside in the 'build'
  directory, ready to install as is.
- Thanks to to Jed Brown for reporting this via Issue #786, and for
  Devin Matthews and Mo Zhou for their engagement.
- Harmonized the rule in the top-level Makefile for installing blis.pc
  into SHAREDIR/pkgconfig with conventions for others vis-a-vis
  verbosity/non-verbosity.
- (cherry picked from commit 141a6c9)
@fgvanzee
Copy link
Member

@jedbrown Closing this issue for now. Please let us know if you have any further concerns.

fgvanzee added a commit that referenced this issue May 26, 2024
@fgvanzee
Fix incorrect commenting of BLIS_RNTM_INITIALIZER and
ed57f0f 
`BLIS_OBJECT_INITIALIZER`.
- (cherry picked from a316d2c)

Update BLIS_*_INITIALIZER macros for C++ compatibility. (#802)

Details:
- Remove designated initializer syntax. This isn't officially supported
  until C++20.
- Arrange initializers in the order in which they are defined in the
  struct. Even with standard or extension support for designated
  initializers, initializing non-static members out-of-order is an
  error in C++.
- Remove the conditional code which uses '-1' as the default value of
  the 'pack_buf' member of 'mem_t' in C, but 'BLIS_BUFFER_FOR_GEN_USE'
  in C++. Simply use the latter as a common-sense default.
- (cherry picked from 664cc6b)

Add cpu part codes for various manufacturers and use in the code (#794)

* Add cpu_id symbols for arm v8.

* Add symbols for arm v7.

* Always assume firestorm on Apple aarch64.

* Fixes incorrect usage of model vs. part in some places.

* Fixes #793
- (cherry picked from 1a8c818)

Fix errors and typos in docs/BLIS*API.md (#791)

Details:
- Fixed errors and unified formatting in docs/BLIS*API.md docs.
- (cherry picked from c382d8b)

Include bli_config.h before bli_system.h in cblas.h. (#789)

Details:
- Previously, in cblas.h, bli_config.h was being #included *after*
  bli_system.h, which meant that the BLIS_ENABLE_SYSTEM macro was
  never defined in time for proper OS detection. This bug only
  affected cblas.h -- blis.h had been correctly #including
  bli_config.h before bli_system.h since fb93d24. Thanks to
  Edward Smyth for reporting this bug and suggesting the fix.
- (cherry picked from a72e456)

Install helper headers to INCDIR prefix. (#787)

Details:
- Install one-line headers to INCDIR whose entire purpose is to
  #include the actual headers within the local 'blis' header directory
  so that applications can #include "blis.h" instead of #include
  <blis/blis.h> (and/or "cblas.h" instead of <blis/cblas.h> if CBLAS is
  enabled) when headers are installed to global paths. (Note that
  INCDIR is the installation prefix for headers as specified by
  '--includedir=INCDIR', which defaults to 'PREFIX/include' if not
  specified.) Not sure how this problem went unreported for so long,
  since presumably any user trying to #include "blis.h" from a global
  installation would have encountered a compiler error.
- The one-line blis.h and cblas.h headers now reside in the 'build'
  directory, ready to install as is.
- Thanks to to Jed Brown for reporting this via Issue #786, and for
  Devin Matthews and Mo Zhou for their engagement.
- Harmonized the rule in the top-level Makefile for installing blis.pc
  into SHAREDIR/pkgconfig with conventions for others vis-a-vis
  verbosity/non-verbosity.
- (cherry picked from 141a6c9)

Allow users to defines [sd]complex using std::complex (#784)

Details:
- In C++ applications, it makes a lot of sense to interface to BLIS
  using C++'s standard complex number library, which uses a template
  class std::complex. Obviously BLIS doesn't know anything about this
  and defaults to a custom struct to represent complex numbers. This PR
  updates the bli_[cz]{real,imag}() functions to accept std::complex
  numbers when a C++ compiler is being used. Note that this has no
  effect on the compilation of the BLIS library (or testsuite), and only
  comes into play when including blis.h into a C++ project and forcing
  the use of std::complex for scomplex and dcomplex.
- The application can explicitly request std:complex-based types via:

    #define BLIS_ENABLE_STD_COMPLEX
    #include <blis.h>
    // Call BLIS functions using std::complex<double> here.

- Fixed a bug in the definition of some scalar level-0 macros, since
  bli_creal()/bli_cimag() and bli_zreal()/bli_zimag() are no longer
  interchangeable.
- (cherry picked from 2d94392)

CREDITS file update.

- (cherry picked from f7ce54a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jedbrown @fgvanzee @cdluminate