bugGNU Octave - Bugs: bug #48775, provide pkg-config file

 
 

bug #48775: provide pkg-config file

Submitter:  Carnë Draug <carandraug>
Submitted:  Sat 13 Aug 2016 11:39:35 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 18 May 2018 10:28:51 AM UTC, comment #8: 

rebased, adapted, and pushed

Carnë Draug <carandraug>
Group Member
Mon 29 Aug 2016 02:40:30 PM UTC, comment #7: 

To be clear, with LIBOCTAVE_LINK_DEPS, I get this octave.pc file:


Name: GNU Octave
Description: C++ interface to GNU Octave underlying library.
URL: http://www.octave.org
Version: 4.1.0+
Requires:
Requires.private:
Libs: -L/home/carandraug/.local/lib/octave/4.1.0+ -loctave
Libs.private:              -lcurl -lcholmod -lumfpack -lamd -lcamd -lcolamd -lccolamd -lcxsparse -larpack -lqrupdate -lfftw3_threads -lfftw3  -lfftw3f_threads -lfftw3f   -lopenblas -lreadline -lncurses  -lpcre -ldl   -L/usr/lib/gcc/x86_64-linux-gnu/4.9 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -lgfortran -lm -lquadmath -lutil -lm
Cflags: -I/home/carandraug/.local/include/octave-4.1.0+/octave/..


and this octinterp.pc


Name: GNU Octave
Description: C++ interface to GNU Octave interpreter.
URL: http://www.octave.org
Version: 4.1.0+
Requires: octave = 4.1.0+
Requires.private:
Libs: -L/home/carandraug/.local/lib/octave/4.1.0+ -loctinterp
Libs.private:
Cflags: -I/home/carandraug/.local/include/octave-4.1.0+/octave/..


Are those flags correct or are liboctinterp flags bleeding into LIBOCTAVE_LINK_DEPS ?

Carnë Draug <carandraug>
Group Member
Fri 19 Aug 2016 01:33:35 AM UTC, comment #6: 

I integrated this better on the build system and dropped octgui.pc
https://bitbucket.org/carandraug/octave/commits/3a73a4640578122ada6751d418de777c7284c04c?at=pkg-config

However, I can't find LIBOCTINERP_LINK_DEPS.  I also noticed that LIBOCTAVE_LINK_DEPS includes lncurses and lreadline which I thought would only be used by octinterp.

Carnë Draug <carandraug>
Group Member
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.

Carnë Draug <carandraug>
Group Member
Thu 18 Aug 2016 06:09:29 PM UTC, comment #4: 

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?

Mike Miller <mtmiller>
Group Member
Thu 18 Aug 2016 01:19:45 PM UTC, comment #3: 

This changes https://bitbucket.org/carandraug/octave/commits/branch/pkg-config will create a pkg-config file for liboctave. I'm not super familiar with automake to add 3 of them the build system properly. Should we have one libinterp/octave/gui_pkgconfig_DATA which gets added to a general pkgconfig_DATA ? Should these go into CLEANFILES or into one of the other X_CLEANFILES ?

After installing, I now get this:


$ export PKG_CONFIG_PATH=/home/carandraug/.local/lib/pkgconfig/
$ pkg-config --libs octave
-L/home/carandraug/.local/lib/octave/4.1.0+ -loctave
$ pkg-config --cflags octave
-I/home/carandraug/.local/include/octave-4.1.0+/octave


Shouldn't the include path be "/home/carandraug/.local/include/octave-4.1.0+/" instead? So that applications would do "#include <octave/Array.h>" ?

Carnë Draug <carandraug>
Group Member
Wed 17 Aug 2016 11:45:34 PM UTC, comment #2: 

I found that our pkg.m4 is out of date. The latest version of the file distributed with Debian stable already comes with a macro, named PKG_INSTALLDIR, to configure the directory where the pc files should be installed.

There are other subtle changes too. This is Debian stable, more recent versions of pkg-config may have even more different macros. Should we update ours?

Carnë Draug <carandraug>
Group Member
Wed 17 Aug 2016 10:11:45 PM UTC, comment #1: 

If I understand pkg-config correctly (it's documentation is pretty much its man page), then this should do it?

I guess we should two more for octinterp and octgui?


Name: GNU Octave
Description: C++ interface to GNU Octave underlying library.
URL: http://www.octave.org
Version: %OCTAVE_VERSION%
Requires:
Requires.private:
Libs: -L%OCTAVE_OCTLIBDIR% -loctave
Libs.private: %OCTAVE_CONF_LIBS%
Cflags: -I%OCTAVE_OCTINCLUDEDIR%


Carnë Draug <carandraug>
Group Member
Sat 13 Aug 2016 11:39:35 PM UTC, original submission:  

Opened new bug report from the discussion on bug #48678.

jwe said on bug #48678

> we provide octave-config and not a pkg-config file is really just historical (pkg-config wasn't around yet?). Switching to pkg-config and deprecating octave-config is probably worthy of a separate bug report/feature request.

Carnë Draug <carandraug>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by carandraug (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-18 carandraug StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code