Feature Request: Add Cflags.private fragment #50

ariadne · 2013-08-14T05:58:49Z

tonytheodore commented

2013-08-14 05:58:49 +00:00

(Migrated from github.com)

Hi,

This is copied from the freedesktop request.

The Libs.private setting is a very handy way to handle static as well as shared library builds.

However, when (cross-)compiling for the Windows platform, this is not always sufficient. The libraries need extra "dllexport" declarations in the headers when building a shared library. Those can usually be suppressed (for static linking) by something like -DTHISLIBRARY_STATIC. It would avoid lots of nasty code if "pkg-config --cflags --static" could take care of that. It might be as simple as:

Cflags.private: -DTHISLIBRARY_STATIC

These changes are a naive implementation of the required behaviour - it basically mimics that of Libs.private.

pkgconf --cflags baz
-fPIC -I/usr/include/foo

pkgconf --cflags --static baz
-fPIC -I/usr/include/foo -DFOO_STATIC

I understand there is a spec in progress, but this functionality would be very handy at the moment.

Thanks,

Tony

Hi, This is [copied from the freedesktop request](https://bugs.freedesktop.org/show_bug.cgi?id=47996). The Libs.private setting is a very handy way to handle static as well as shared library builds. However, when (cross-)compiling for the Windows platform, this is not always sufficient. The libraries need extra "dllexport" declarations in the headers when building a shared library. Those can usually be suppressed (for static linking) by something like -DTHISLIBRARY_STATIC. It would avoid lots of nasty code if "pkg-config --cflags --static" could take care of that. It might be as simple as: Cflags.private: -DTHISLIBRARY_STATIC These changes are a naive implementation of the required behaviour - it basically mimics that of Libs.private. ``` sh pkgconf --cflags baz -fPIC -I/usr/include/foo pkgconf --cflags --static baz -fPIC -I/usr/include/foo -DFOO_STATIC ``` I understand there is a [spec in progress](http://dev.gentoo.org/~mgorny/pkg-config-spec.html), but this functionality would be very handy at the moment. Thanks, Tony

ariadne commented

2013-08-19 03:17:15 +00:00

Can you point me to a realworld use-case for this? I am not sure I want to break compatibility with Freedesktop pkg-config unless there is a realworld use-case for this.

ariadne commented

2013-08-19 03:19:31 +00:00

Aha. I see the use-case on the Freedesktop bug. I disagree with the new maintainer that it would break backwards compatibility. At worst case, already broken behaviour would be retained.

So, I will merge this.

Aha. I see the use-case on the Freedesktop bug. I disagree with the new maintainer that it would break backwards compatibility. At worst case, already broken behaviour would be retained. So, I will merge this.

tonytheodore commented

2013-08-19 08:40:20 +00:00

(Migrated from github.com)

Great - thanks! That will save lots of workarounds we (mxe.cc) use for static windows builds. Now we can convert those to clean patches that will be harmless upstream and bundle pkgconf for our users since it's so easy to build. It also allows more flexibility with future shared builds and I don't imagine the semantics of this fragment will change materially through the spec process - so it's a win all round.

I mentioned that this was a "naive" implementation - it's impressive that all the parsing and traversal logic is encapsulated and the seemingly obvious actually works. Kudos to the designers.

Cheers,

Tony

Great - thanks! That will save lots of workarounds we (mxe.cc) use for static windows builds. Now we can convert those to clean patches that will be harmless upstream and bundle pkgconf for our users since it's so easy to build. It also allows more flexibility with future shared builds and I don't imagine the semantics of this fragment will change materially through the spec process - so it's a win all round. I mentioned that this was a "naive" implementation - it's impressive that all the parsing and traversal logic is encapsulated and the seemingly obvious actually works. Kudos to the designers. Cheers, Tony

Sign in to join this conversation.

No reviewers