RFC: Feature requests for 1.8.0 #220

New Issue

ariadne · 2021-03-29T22:14:48Z

ariadne commented

2021-03-29 22:14:48 +00:00

I think pkgconf is largely a "done" topic as @ddevault mentions.

So I would like to set up a 1.8.0 branch that is basically long-term maintenance until the project is no longer needed.

What kinds of things would people like to see in such a capstone branch?

I think pkgconf is largely a "done" topic as @ddevault mentions. So I would like to set up a 1.8.0 branch that is basically long-term maintenance until the project is no longer needed. What kinds of things would people like to see in such a capstone branch?

ariadne commented

2021-03-29 22:17:00 +00:00

Poster

I think one nice thing to have would be reworked manpages using scdoc. What do people think of that?

ddevault commented

2021-03-29 22:18:59 +00:00

(Migrated from github.com)

Poster

As the maintainer of scdoc, I will abstain from any subjective judgements on its utility to pkgconf.

Speaking only of the facts, scdoc is not a burden on the build process. It is written in standards-conformant C99 and targets a minimal subset of POSIX. It supports reproducible builds.

As the maintainer of scdoc, I will abstain from any subjective judgements on its utility to pkgconf. Speaking only of the facts, scdoc is not a burden on the build process. It is written in standards-conformant C99 and targets a minimal subset of POSIX. It supports reproducible builds.

drhpc commented

2021-07-23 12:50:25 +00:00

(Migrated from github.com)

Poster

I'd like the library (and include) path mangling to be completed, not just filtering -L/foo/lib if /foo/lib is in LIBRARY_PATH, but also -Wl,-R/foo/lib if it is in LD_RUN_PATH. I'm in the process of hacking up a patch for that … just trying to figure out how to enable the tracing in the library help me find the spots …

Edit: Maybe I'll wait for feedback on the idea. I could also disable the source of those Wl,-R in pkg-config files from pkgsrc builds, since they are not that usual, anyway.

I'd like the library (and include) path mangling to be completed, not just filtering -L/foo/lib if /foo/lib is in LIBRARY_PATH, but also -Wl,-R/foo/lib if it is in LD_RUN_PATH. I'm in the process of hacking up a patch for that … just trying to figure out how to enable the tracing in the library help me find the spots … Edit: Maybe I'll wait for feedback on the idea. I could also disable the source of those Wl,-R in pkg-config files from pkgsrc builds, since they are not that usual, anyway.

👍 1

ariadne commented

2021-07-25 01:49:03 +00:00

Poster

Seems like a useful feature, but not sure how to do it in a clean way.

drhpc commented

2021-07-25 07:51:10 +00:00

(Migrated from github.com)

Poster

You mean because of the variants (-Wl -W-R/foo/lib, -Wl,-rpath=/foo/lib, etc.)? That's for sure inconvenient but I guess the possibilities can be enumerated. The rest seems identical to the handling of -L …

You mean because of the variants (`-Wl -W-R/foo/lib`, `-Wl,-rpath=/foo/lib`, etc.)? That's for sure inconvenient but I guess the possibilities can be enumerated. The rest seems identical to the handling of `-L` …

👍 1

ariadne commented

2021-07-25 09:51:09 +00:00

Poster

Internally, the -Wl,... flags are stored as {'W', 'l,...'} is the problem. So filtering -L is easy, but rpath and stuff like that not so much. I do agree we should do it though.

Internally, the -Wl,... flags are stored as `{'W', 'l,...'}` is the problem. So filtering `-L` is easy, but rpath and stuff like that not so much. I do agree we should do it though.

👍 2

Sign in to join this conversation.