Thu 18 Aug 2016 07:13:49 PM UTC, comment #5:
> * 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.
|