[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave f
From: |
Mike Miller |
Subject: |
[Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time |
Date: |
Fri, 6 Jul 2018 13:47:37 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 |
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/
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time,
Mike Miller <=
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time, John Donoghue, 2018/07/06
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time, Mike Miller, 2018/07/06
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time, John W. Eaton, 2018/07/06
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time, Mike Miller, 2018/07/06
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time, Mike Miller, 2018/07/06
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time, John W. Eaton, 2018/07/06
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time, John W. Eaton, 2018/07/06
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time, John W. Eaton, 2018/07/06
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time, Mike Miller, 2018/07/06
- [Octave-bug-tracker] [bug #54260] mkoctfile doesn't export some Octave features that packages need at build time, Mike Miller, 2018/07/06