octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mike Miller
Subject: [Octave-bug-tracker] [bug #48775] provide pkg-config file
Date: Thu, 18 Aug 2016 18:09:29 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0

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

Comments:

* 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 don't think we should install a .pc file for octgui. The header files are
not installed, the library may not be installed as libraries intended for
external use (e.g. dpkg -L liboctave-dev | grep "lib.*so"). It is essentially
a private library.
* I don't think you need to comment where pkgconfigdir comes from.
* If you do want to have two .pc files for liboctave vs liboctinterp, the
liboctinterp one should use the "Requires" tag to depend on liboctave's .pc
file.
* I think Libs.private should use the LIBOCTAVE_LINK_DEPS and
LIBOCTINERP_LINK_DEPS variables. The Libs.private options is usually used when
you want to do static linking, which requires the *full* list of libraries
that the lib in question needs to be linked against. I think this is also
recursive with respect to the "Requires" tag, so no need to list them twice.
* 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.
* Since the files are built by configure, the rules should automatically be in
place to delete them on "make distclean".

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?

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]