split pkgconf core into libpkg library #12

New Issue

There is no status yet, there's a few issues I want to figure out first, such as a portable build system which supports libraries in a robust way (we basically have that), as well as some core changes needed to ensure the library can be used with the same ease of use as the pkgconf utility itself.

wycats commented

2014-07-07 16:57:58 +00:00

(Migrated from github.com)

Poster

@kaniini we're looking into bundling pkgconf with a syntax extension for Rust, and obviously a library would be nicer than shelling out to an executable. That works for now, though 😄

@kaniini we're looking into bundling pkgconf with a syntax extension for Rust, and obviously a library would be nicer than shelling out to an executable. That works for now, though :smile:

ariadne commented

2014-07-09 05:22:01 +00:00

Poster

@wycats yeah, the idea is to eventually make pkg-config(1) interface obsolete of course. if you guys are interested in working on that, i'd love to merge something. otherwise i might have time to look at it in august.

ariadne commented

2015-09-03 08:22:50 +00:00

Poster

@wycats out of curiosity, would an API giving you a pre-formatted string be useful? or do you just want to iterate over the raw pkg_fragment_t's like pkgconf itself does?

@wycats out of curiosity, would an API giving you a pre-formatted string be useful? or do you just want to iterate over the raw `pkg_fragment_t`'s like pkgconf itself does?

wycats commented

2015-09-03 11:27:45 +00:00

(Migrated from github.com)

Poster

What would the preformatted string look like?

ariadne commented

2015-09-04 22:22:38 +00:00

Poster

the pre-formatted string would be basically, the same result as pkgconf --cflags or pkgconf --libs. the reason why i mentioned the lower-level option is because it may be more useful to you to get at the lower-level flags so that you can translate them as needed for Rust.

the pre-formatted string would be basically, the same result as `pkgconf --cflags` or `pkgconf --libs`. the reason why i mentioned the lower-level option is because it may be more useful to you to get at the lower-level flags so that you can translate them as needed for Rust.

wycats commented

2015-09-06 09:37:11 +00:00

(Migrated from github.com)

Poster

I could see some benefit from both options. The preformatted string would be easier to migrate from, but the lower level option would give us more control in the long term.

Any reason not to do both?

I could see some benefit from both options. The preformatted string would be easier to migrate from, but the lower level option would give us more control in the long term. Any reason not to do both?

ariadne commented

2015-09-07 03:30:25 +00:00

Poster

There's no problem with providing both interfaces.

In that case, would an interface like:

pkgconf_err_return_t pkgconf_pkg_cflags_as_string(pkg_t *root, char *buffer, size_t size, int maxdepth, unsigned int flags);

work for you guys?

The only downside is that it would use a buffer, so really long cflags strings might be truncated.

A better interface would be in my opinion, one which delivers preformatted fragments back to a callback, and allows the callee to handle buffering them. But I'm not sure if you guys can do that easily.

There's no problem with providing both interfaces. In that case, would an interface like: ``` pkgconf_err_return_t pkgconf_pkg_cflags_as_string(pkg_t *root, char *buffer, size_t size, int maxdepth, unsigned int flags); ``` work for you guys? The only downside is that it would use a buffer, so really long cflags strings might be truncated. A better interface would be in my opinion, one which delivers preformatted fragments back to a callback, and allows the callee to handle buffering them. But I'm not sure if you guys can do that easily.

ariadne commented

2016-12-02 07:20:51 +00:00

Poster

Only a few things remaining here. Most likely this is being cut as of end of next week!

handle pc_sysrootdir and other builtins (probably have a function to optionally install these)
handle fragment rendering to string and updating the CLI client to use it (not a big deal)

Only a few things remaining here. Most likely this is being cut as of end of next week! - [x] handle `pc_sysrootdir` and other builtins (probably have a function to optionally install these) - [x] handle fragment rendering to string and updating the CLI client to use it (not a big deal)

plicease commented

2016-12-02 19:19:51 +00:00

(Migrated from github.com)

Poster

Is there any documentation (aside from libpkgconf.h) or examples (aside from main.c)? Something like this: https://github.com/libarchive/libarchive/wiki/Examples would be helpful for getting started?

Is there any documentation (aside from `libpkgconf.h`) or examples (aside from `main.c`)? Something like this: https://github.com/libarchive/libarchive/wiki/Examples would be helpful for getting started?

ariadne commented

2016-12-02 21:23:59 +00:00

Poster

We are working on docs for it, but haven't really decided our plan there yet. We will probably go with Sphinx or similar and include some examples, but the cleanup isn't fully done yet so right now I'm concentrating on that.