Hello everyone,
I have designated git master as pkgconf 1.9.90, which means the
pkgconf 2.0 development cycle has officially begun!
Here are some of my plans for pkgconf 2.0, if anyone is interested in
helping with them, feel free to let me know.
* Testsuite changes
I want to move our testsuite away from ATF to something based on TAP.
Kyua can run either ATF or TAP tests, so switching to TAP will allow
for other harnesses to be used, such as the one built into Meson.
Kyua and ATF tests only work well on UNIX systems as well, so this
allows for us to start doing automated CI on Windows as well (assuming
someone wants to do the work to enable that.)
I also want to begin testing of libpkgconf internals themselves. This
work would be done after the ATF-based testsuite is ported to use a
TAP implementation instead.
* Generic support for fragment lists
pkg-config has traditionally had support for three fragment lists:
CFLAGS, LIBS and LIBS.private. pkgconf added support for a forth:
CFLAGS.private.
However, there are other languages and toolchains out there besides
the C/C++ toolchain. It would be nice to have something like:
FragmentList-cflags: -Ifoo -DBAR -fbaz
FragmentList-libs: -lfoo
This automatically makes it possible for pkgconf to support fragment
lists for other toolchains transparently. Internally, we would
rewrite CFLAGS and LIBS legacy fragment lists to use the same logic.
We will want to add appropriate hooks to the contracts so we can teach
pkgconf about the requirements of these other toolchains, of course,
as we do for stuff like -isystem and -framework today with gcc/clang.
What do you all think?
Ariadne
On Sun, Aug 4, 2019 at 6:39 PM Ariadne Conill <ariadne@dereferenced.org> wrote:
>> Hello everyone,>> I have designated git master as pkgconf 1.9.90, which means the> pkgconf 2.0 development cycle has officially begun!>
That's weird. Neither the (afaik) primary git[1] nor its pagure
mirror[2] have that tag. Did you move the primary git to a new
location?
[1]: https://git.dereferenced.org/pkgconf/pkgconf
[2]: https://pagure.io/pkgconf/pkgconf> Here are some of my plans for pkgconf 2.0, if anyone is interested in> helping with them, feel free to let me know.>> * Testsuite changes>> I want to move our testsuite away from ATF to something based on TAP.> Kyua can run either ATF or TAP tests, so switching to TAP will allow> for other harnesses to be used, such as the one built into Meson.> Kyua and ATF tests only work well on UNIX systems as well, so this> allows for us to start doing automated CI on Windows as well (assuming> someone wants to do the work to enable that.)>
So does this mean we'll eventually be able to run the tests just with
Meson (no kyua build dependency)? From my perspective, that might be
compelling enough for me to change over both Fedora and Mageia
packaging to Meson.
> I also want to begin testing of libpkgconf internals themselves. This> work would be done after the ATF-based testsuite is ported to use a> TAP implementation instead.>> * Generic support for fragment lists>> pkg-config has traditionally had support for three fragment lists:> CFLAGS, LIBS and LIBS.private. pkgconf added support for a forth:> CFLAGS.private.>> However, there are other languages and toolchains out there besides> the C/C++ toolchain. It would be nice to have something like:>> FragmentList-cflags: -Ifoo -DBAR -fbaz> FragmentList-libs: -lfoo>> This automatically makes it possible for pkgconf to support fragment> lists for other toolchains transparently. Internally, we would> rewrite CFLAGS and LIBS legacy fragment lists to use the same logic.> We will want to add appropriate hooks to the contracts so we can teach> pkgconf about the requirements of these other toolchains, of course,> as we do for stuff like -isystem and -framework today with gcc/clang.>> What do you all think?
Would this also make it easier for handling languages like D, which
currently have very poor support in pkgconfig today?
--
真実はいつも一つ！/ Always, there's only one truth!
Hello,
On Sun, Aug 4, 2019 at 6:40 PM Neal Gompa <ngompa13@gmail.com> wrote:
>> On Sun, Aug 4, 2019 at 6:39 PM Ariadne Conill <ariadne@dereferenced.org> wrote:> >> > Hello everyone,> >> > I have designated git master as pkgconf 1.9.90, which means the> > pkgconf 2.0 development cycle has officially begun!> >>> That's weird. Neither the (afaik) primary git[1] nor its pagure> mirror[2] have that tag. Did you move the primary git to a new> location?>> [1]: https://git.dereferenced.org/pkgconf/pkgconf> [2]: https://pagure.io/pkgconf/pkgconf
I am still working out how to automatically sync the mirrors. The
canonical location is indeed now on sourcehut.
> > Here are some of my plans for pkgconf 2.0, if anyone is interested in> > helping with them, feel free to let me know.> >> > * Testsuite changes> >> > I want to move our testsuite away from ATF to something based on TAP.> > Kyua can run either ATF or TAP tests, so switching to TAP will allow> > for other harnesses to be used, such as the one built into Meson.> > Kyua and ATF tests only work well on UNIX systems as well, so this> > allows for us to start doing automated CI on Windows as well (assuming> > someone wants to do the work to enable that.)> >>> So does this mean we'll eventually be able to run the tests just with> Meson (no kyua build dependency)? From my perspective, that might be> compelling enough for me to change over both Fedora and Mageia> packaging to Meson.
Yes, it will be possible. However, you will need to be careful with
using Meson to build pkgconf, as pkgconf is needed early in the
bootstrap process for most distributions.
> > I also want to begin testing of libpkgconf internals themselves. This> > work would be done after the ATF-based testsuite is ported to use a> > TAP implementation instead.> >> > * Generic support for fragment lists> >> > pkg-config has traditionally had support for three fragment lists:> > CFLAGS, LIBS and LIBS.private. pkgconf added support for a forth:> > CFLAGS.private.> >> > However, there are other languages and toolchains out there besides> > the C/C++ toolchain. It would be nice to have something like:> >> > FragmentList-cflags: -Ifoo -DBAR -fbaz> > FragmentList-libs: -lfoo> >> > This automatically makes it possible for pkgconf to support fragment> > lists for other toolchains transparently. Internally, we would> > rewrite CFLAGS and LIBS legacy fragment lists to use the same logic.> > We will want to add appropriate hooks to the contracts so we can teach> > pkgconf about the requirements of these other toolchains, of course,> > as we do for stuff like -isystem and -framework today with gcc/clang.> >> > What do you all think?>> Would this also make it easier for handling languages like D, which> currently have very poor support in pkgconfig today?
Yes, this is precisely what this is for, stuff like D and Fortran and so on.
Ariadne
Hello,
On Sun, Aug 4, 2019 at 6:47 PM Ariadne Conill <ariadne@dereferenced.org> wrote:
>> Hello,>> On Sun, Aug 4, 2019 at 6:40 PM Neal Gompa <ngompa13@gmail.com> wrote:> >> > On Sun, Aug 4, 2019 at 6:39 PM Ariadne Conill <ariadne@dereferenced.org> wrote:> > >> > > Hello everyone,> > >> > > I have designated git master as pkgconf 1.9.90, which means the> > > pkgconf 2.0 development cycle has officially begun!> > >> >> > That's weird. Neither the (afaik) primary git[1] nor its pagure> > mirror[2] have that tag. Did you move the primary git to a new> > location?> >> > [1]: https://git.dereferenced.org/pkgconf/pkgconf> > [2]: https://pagure.io/pkgconf/pkgconf>> I am still working out how to automatically sync the mirrors. The> canonical location is indeed now on sourcehut.>> > > Here are some of my plans for pkgconf 2.0, if anyone is interested in> > > helping with them, feel free to let me know.> > >> > > * Testsuite changes> > >> > > I want to move our testsuite away from ATF to something based on TAP.> > > Kyua can run either ATF or TAP tests, so switching to TAP will allow> > > for other harnesses to be used, such as the one built into Meson.> > > Kyua and ATF tests only work well on UNIX systems as well, so this> > > allows for us to start doing automated CI on Windows as well (assuming> > > someone wants to do the work to enable that.)> > >> >> > So does this mean we'll eventually be able to run the tests just with> > Meson (no kyua build dependency)? From my perspective, that might be> > compelling enough for me to change over both Fedora and Mageia> > packaging to Meson.>> Yes, it will be possible. However, you will need to be careful with> using Meson to build pkgconf, as pkgconf is needed early in the> bootstrap process for most distributions.
As an update on this, I have designed a TAP-compliant test framework
in POSIX shell[1]. I will port the pkgconf test suite to use it over
the next few days.
[1]: https://git.sr.ht/~kaniini/tap-sh
Ariadne