[Octave-bug-tracker] [bug #38928] configure -> hdf5 doesn't handle path through

[Rik]

Follow-up Comment #25, bug #38928 (project octave):

I think the change from FT2_CFLAGS to FT2_CPPFLAGS needs to be reverted.  The
CPPFLAGS variable is undefined, while the FT2_CFLAGS correctly has the -I
options for the library.

The issue is that configure.ac uses the PKG_CHECK_MODULES macro as the
interface between Autotools and pkg-config and the output of the macro is only
XXX_CFLAGS and XXX_LIBS.  Documentation on the macro is at
https://autotools.io/pkgconfig/pkg_check_modules.html.  Alternatively, we
could spin up our own m4 macro to use the --cflags-only-I option of
pkg-config, but this seems like more work.

I also don't think we need to add all of the CPPFLAGS (FT2_CPPFLAGS,
HDF5_CPPFLAGS, Z_CPPFLAGS, FFTW_XCPPFLAGS, LLVM_CPPFLAGS) to AM_CPPFLAGS in
libinterp/Makefile.am.  The module.mk files in the subdirectories go to the
trouble to apply the CPPFLAGS only to the files that need them.  The
convenience libraries in the subdirectories are then linked together into
libinterp, but CPPFLAGS isn't required for that step.  For instance, the
parse-tree directory has no need to see the FFTW_XCPPFLAGS during compilation.
 Another example comes from corefcn/module.mk where there is this comment: 


## Special rules for FreeType .df files so that not all .df files are built
## with FT2_CPPFLAGS, FONTCONFIG_CPPFLAGS


HDF5_CPPFLAGS probably does need to be snuck into AM_CPPFLAGS because it gets
so widely included through ov.h that it is essentially used everywhere in
libinterp.

I would say that the same considerations also apply to liboctave/Makefile.am. 
Most of liboctave does not need FFTW_XCPPFLAGS or ARPACK_CPPFLAGS.  Only a few
files in the numeric directory need those, and so only that convenience
library is built with those CPPFLAGS.  QRUPDATE_CPPFLAGS could be added to the
file numeric/module.mk since that is currently missing.

CURL_CPPFLAGS should probably just go into util/module.mk since there is only
one file there that uses them.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?38928>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/