[Octave-bug-tracker] [bug #48775] provide pkg-config file

[Carnë Draug]

Follow-up Comment #5, bug #48775 (project octave):

> * Do we want to keep updating / maintaining pkg.m4 or just drop it? I looked
at deleting it a while ago, but decided against it because some distros still
have old versions of pkg-config.

I'm usually on favour of relying on the system having the dependency available
of the right version but I feel that autoconf macros are not really designed
for that. If the users has a different version on the system, it could lead to
weird bugs during configure. And once Octave installed, it's not like the
dependency makes any difference or needs to be kept up to date.

> * Historically the include path has been set with "-I$(octincludedir)
-I$(octincludedir)/.." so that either method of including the headers works.
Maybe our headers and API are improving so we can now just use
-I$(the_directory_above_octincludedir), maybe we need a new make variable to
do that in a clean way.

But historically we didn't really support use of liboctave elsewhere other
than oct files. I think we should give cleaner flags so that we don't end up
shadowing other headers.

> Overall, the decision on whether to split the pkg-config flags between one
or two files (ignoring liboctgui) is important. Currently users have no way
(with octave-config or mkoctfile) to build something against just liboctave,
and I think that's what you are trying to make possible here. OTOH, also
consider what the user expects when they run "pkg-config --libs octave".
Should that be the full flags needed to build an oct file or an embedded
Octave interpreter?

Yes, I am trying to make possible to use just liboctave. I believe that most
users of pkg-config will be interested on liboctave only which is why I'm
splitting it in two.

People building oct files will mainly be using mkoctfile which would handle
all the flags for them. Checking all the configure.ac in Octave Forge, image
uses it to check for the new namespace; struct, database, and optim use it to
check how Octave handles errors; and communication packages checks hdf5 type
plus other things in octave_value (I actually thought this would be less
common).

Anyway, if liboctave and liboctinterp are two separate libraries, and I think
we are treating them like that, then it would make sense to use the library
name on pkg-config call.

    _______________________________________________________

Reply to this item at:

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

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