[Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time

[Mike Miller]

URL:
  <http://savannah.gnu.org/bugs/?54260>

                 Summary: mkoctfile doesn't export some Octave features that
packages need at build time
                 Project: GNU Octave
            Submitted by: mtmiller
            Submitted on: Fri 06 Jul 2018 10:47:35 AM PDT
                Category: Configuration and Build System
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Feature Request
                  Status: Confirmed
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: GNU/Linux

    _______________________________________________________

Details:

Several Octave Forge packages use some equivalent of "octave --eval", or the
octave-config program, to get information about how Octave was configured or
built. I'm trying to summarize the features that all packages need (for now),
so they can potentially be added to mkoctfile to have one place where all
packages can get the information they need.

* CANONICAL_HOST_TYPE is only exported by 'octave-config -p', not 'mkoctfile
-p'. Both database and fl-core (unmaintained) check CANONICAL_HOST_TYPE to see
if it contains 'mingw' to add certain libraries to the link stage. The gsl
package uses 'octave --eval' to get the same variable for similar purposes.
The windows package uses it for OS-dependent logic (how to copy files, whether
to strip object files).

* VERSION is also only exported by 'octave-config -p', not 'mkoctfile -p'. is
used by both the optiminterp and windows package to define a HAVE_OCTAVE_440
preprocessor symbol, for example, but I don't see that those symbols are
actually used in any code.

* LOCALVERFCNFILEDIR, LOCALVEROCTFILEDIR, LOCALVERARCHLIBDIR are all again
from 'octave-config -p', used only by the windows package, and I'm not sure
why it needs them. I see that they are AC_SUBST'd, but I don't think the build
uses them now, maybe once upon a time.

* PCRE_CPPFLAGS and PCRE_LIBS are used by the strings package, and they are
queried with 'octave --eval'. Should a package rely on how Octave determined
it was to be built against an external library, or should it use its own
logic?

* HDF5_CPPFLAGS, HDF5_LDFLAGS, and HDF5_LIBS are used by the communications
package and they are queried with 'octave --eval'. Same question as above,
should a package rely on Octave to tell it how to link with external
libraries?

* octincludedir is used by the gsl package to add a -I option to CPPFLAGS.
Shouldn't this be implicit in mkoctfile? I'm not sure why this is needed at
all.

* Whether the index integer is 32-bit or 64-bit can only be derived with
'octave --eval' at the moment. The sparsersb package uses that at build time
to add a preprocessor symbol to conditionally compile some functions one way
or another. Is there or can we add an easier way for a package to know the
size of the octave_idx_type at build time?

A lot of these are questions of the form "Do we need this?"

Anyone may add more to this list if I missed any features that Octave Forge
packages currently use at build time that can't be derived from mkoctfile
alone.

I'm leaving out a big category of packages, which are packages that ask Octave
whether a function or several functions are defined on the core load path,
which it then uses to conditionally install its own m-files. This happens when
a function is moved from Octave core into a package, or vice versa, and the
package wants to be compatible with more than one release while not abiding
annoying 'shadows a core library function' warning messages. I think that
requires a different general treatment for cross-compiling than the goal of
this bug.




    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/