RFC: Porting to C++ #218
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
The majority of
pkgconfis basically data structures and string manipulation code.By porting
pkgconfto C++, we could drop most of the boring code and focus strictly on the pkgconf functionality itself. Although this would likely make the executable heavier, this would in trade make maintenance a lot simpler.What do people think about this idea?
From a project observer perspective:
If it becomes heavier depends on which parts of C++ you are using.
With C++ you can for sure focus on relevant parts, since due RAII (constructor, destructor) resource management becomes a no issue, and through using of data types like std::array std::vector, buffer overflows are non existing, basically.
That said, C++ has kind of a learning curve, due to its size it takes some time and experience to find the right subset of the language that works for a project and the involved people. But if you find that, C++ can be superior to C in any aspect.
For a core system dependency I strongly suggest targeting C99.
Strong NACK.
Why? You need g++ to build gcc anyway. You need g++ or clang++ to build clang.
There is more than one C compiler out there.
Yes, but the ones I mentioned are the system compilers for all of the platforms that pkgconf formally supports. So it does not change the bootstrap angle.
The alternative would be to add even more code to pkgconf to add Pascal-style strings (like apk-tools does), and port over the object system from apk-tools so we can clean up the vtable use that way.
Porting to C++ instead of the framework built into apk-tools would make the codebase more accessible to new contributors, in my opinion. I am tired of
PKGCONF_ITEM_SIZEandPKGCONF_BUFSIZEand the lack of proper string handling.Why do you formally support any platforms or compilers in the first place? Target a C standard and a POSIX standard.
We target POSIX 2017 at the moment and ISO C11. However, in practice, pkgconf targets contemporary UNIX distributions, and recently, Windows. All of which have a system C++ compiler that supports C++11 or newer.
Would you like to propose an alternative that gives us memory-safe string operations and allows us to cleanly encapsulate the behavior of the multiple areas of the code where we use vtables and similar?
It does not have to be C++, but I would like to use a language and standard library that cleanly supports these concepts. Perhaps the language you are working on?
The language I am working on would be well suited for pkgconf if it were more mature. However, I see no reason to leave C. You seem to have been doing fine with it thus far, and pkgconf is hardly the fastest moving target - nor ought it be. The work required to port it to something else seems to far outweigh the work required to maintain the status quo.
Ultimately the maintenance burden is yours to bear, and thus it is your decision to decide the shape of that burden, but if you make this change, you'll offload some of it onto downstreams and users instead.
Honestly, if pkgconf were rewritten in C++ that would make a strong argument for returning to pkg-config.
Why would it be a strong argument for returning to something that is no longer maintained and embeds a copy of GLib2? I don't understand why switching to C++ over C would add additional burden for a downstream, since they need C++ anyway to build the other components.
Linux, for example, absolutely requires gcc or clang, which require a C++ compiler to build anyway.
I'm fine with importing the framework code we have built to achieve memory-safe stringops in apk (
apk_blob), but am not sure if new developers will be thrilled to use that code.Perhaps not returning to pkg-config (though I'll take Glib over g++ any time), but definitely a strong motivator for a fork.
I thought you targetted POSIX, not Linux. In any case, a C compiler could be written which implements GNU C extensions but does not support C++.
What new developers? As far as I'm concerned, pkgconf is done. Shouldn't you be more concerned with long-term maintenance than with rewrites at this point?
Well, I am sure the BSD kernels also depend on GCC or clang.
I agree with you that pkgconf is mostly a done topic, especially with the introduction of C21/C++20 modules and meson subprojects.
But there are still some imperfections that would require substantive refactoring to properly implement, like #213 (which will require the ability to evaluate a
struct pkgconf_tuple's value at expansion time).So the question becomes -- if I am going to do this refactoring -- how far should I go? I don't think #213 for example is really a deal breaker, but it would be nice to fix properly.
Another question to think about -- if we all agree pkgconf is largely a done topic -- what should a capstone branch look like?
I think it would be nice to convert the man pages to use scdoc, for example.
Ah, yes, the two kernels: Linux and BSD. Pity no one ever wrote anything else /s
You're also in a position to decree that the ecosystem adapt to your idiosyncrasies in exchange for a simpler product. I don't know if #213 is an example of that, but it's something to keep in mind. You have the leverage to choose to be simpler than you could otherwise be.
I think we will stick with C and just port some nice things from apk-tools over. We can talk about other final touches for pkgconf on #220.