After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 719491 - Support generating pkg-config files using valac
Support generating pkg-config files using valac
Status: RESOLVED NOTABUG
Product: vala
Classification: Core
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2013-11-28 13:44 UTC by Philip Withnall
Modified: 2013-12-06 10:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philip Withnall 2013-11-28 13:44:54 UTC
It would be nice if valac could generate the pkg-config file for a library, since I think it should already know all the dependencies, CFLAGS, etc. which are needed in the pkg-config file.

e.g. `valac --library=mylib --pkg-config` should generate mylib.pc.
Comment 1 Luca Bruno 2013-11-28 16:51:34 UTC
The .pc file might include some other variables that you may want to tweak, or also private dependencies. That's why build systems have a .pc.in which gets filled by the configure script. In my opinion, it's not worth it. It's better to write a couple of scripts if you want to automatize this process.
Comment 2 Philip Withnall 2013-11-28 18:38:23 UTC
Vala should know about the private dependencies, shouldn’t it?

How about keeping the .pc.in template, but having Vala fill it out, rather than autoconf?

Basically, it sucks to currently have to manually maintain several almost-identical lists of dependencies for a program or library: the lists in the pkg-config file, the valac flags, and the CFLAGS and LIBS variables. I’ve seen these lists get out of sync numerous times, most commonly the pkg-config list becoming outdated because it’s hidden away in a different file. It seems like generating the pkg-config file is a feasible way of fixing this.
Comment 3 Maciej (Matthew) Piechotka 2013-11-28 18:54:29 UTC
(In reply to comment #2)
> Vala should know about the private dependencies, shouldn’t it?
> 
> How about keeping the .pc.in template, but having Vala fill it out, rather than
> autoconf?
> 


Looking on the file the Vala would know just the Libs, Libs.private and requires. CFLAGS are unknown by default as you might want (and most libraries do that) install in a prefix or other location. Take a one from glib-2.0.pc:

Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include

> Basically, it sucks to currently have to manually maintain several
> almost-identical lists of dependencies for a program or library: the lists in
> the pkg-config file, the valac flags, and the CFLAGS and LIBS variables. I’ve
> seen these lists get out of sync numerous times, most commonly the pkg-config
> list becoming outdated because it’s hidden away in a different file. It seems
> like generating the pkg-config file is a feasible way of fixing this.

I guess you could put the dependency list in configure.ac - you need one for PKG_CHECK_MODULE's anyway as canonical location. From there generating Requires should be trivial.
Comment 4 Philip Withnall 2013-11-28 20:08:09 UTC
(In reply to comment #3)
> I guess you could put the dependency list in configure.ac - you need one for
> PKG_CHECK_MODULE's anyway as canonical location. From there generating Requires
> should be trivial.

Then two lists have to be maintained: one in configure.ac and one in the valac flags. The lists have to contain different things (pkg-config filenames vs. VAPI filenames).

If valac could take pkg-config filenames instead of VAPI filenames for --pkg then that would work.
Comment 5 Maciej (Matthew) Piechotka 2013-11-30 18:05:29 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > I guess you could put the dependency list in configure.ac - you need one for
> > PKG_CHECK_MODULE's anyway as canonical location. From there generating Requires
> > should be trivial.
> 
> Then two lists have to be maintained: one in configure.ac and one in the valac
> flags. The lists have to contain different things (pkg-config filenames vs.
> VAPI filenames).
> 
> If valac could take pkg-config filenames instead of VAPI filenames for --pkg
> then that would work.

I'd guess that this is the root problem. As a side note - I thought that they were supposed to be named in the same way so valac --pkg package checks pkg-config for compiler/linker flags.

As a workaround - you can still have 2 lists kept next to each other in configure.ac so you won't forget to update.
Comment 6 Jürg Billeter 2013-12-01 15:28:05 UTC
(In reply to comment #4)
> If valac could take pkg-config filenames instead of VAPI filenames for --pkg
> then that would work.

VAPI filenames are identical to pkg-config filenames (ignoring the extensions).
Comment 7 Philip Withnall 2013-12-06 10:35:26 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > If valac could take pkg-config filenames instead of VAPI filenames for --pkg
> > then that would work.
> 
> VAPI filenames are identical to pkg-config filenames (ignoring the extensions).

Doh, I never realised that. Looking a little further, the VALA_CHECK_MODULES() macro seems to exactly what’s needed, taking a pkg-config-style list of pkg-config names and versions, performing the pkg-config check, stripping out the versions and performing the Vala module check, then defining *_CFLAGS, *_LIBS and *_VALAFLAGS with the --pkg arguments.

In that case, the following should work (although will need some tweaking to fit in with folks’ build system, since we only perform the Vala module check if compiling with --enable-vala):

configure.ac:
MY_PACKAGES_PUBLIC=glib-2.0 >= 2.38 gio-2.0 >= 2.34 gee-0.8 >= 0.10.1
MY_PACKAGES_PRIVATE=libxml-2.0 >= 0.1
VALA_CHECK_MODULES([MY_LIB],[$MY_PACKAGES_PUBLIC $MY_PACKAGES_PRIVATE])
AC_SUBST([MY_PACKAGES_PUBLIC])
AC_SUBST([MY_PACKAGES_PRIVATE])

my-lib.pc.in:
Name: my-lib
Version: @VERSION@
Requires: @MY_PACKAGES_PUBLIC@
Requires.private: @MY_PACKAGES_PRIVATE@
Libs: -L${libdir} -lmy-lib
Cflags: -I${includedir}/my-lib

Makefile.am:
my_lib_la_CFLAGS = $(MY_LIB_CFLAGS) …
my_lib_la_LIBADD = $(MY_LIB_LIBS) …
my_lib_la_VALAFLAGS = $(MY_LIB_VALAFLAGS) …


Sorry for the noise: I really should have researched this better before opening the bug. Looks like folks’ build system has been stuck too far in the past, and me with it.