Generate placeholder C functions for outdated libraries

[diamondburned]

Generate placeholder C functions for outdated libraries

[founderio]

There is a side effect to this though:
This would, very likely, silently compile if something is missing. And then panic at runtime.

The other approach, while being more space-consuming, will fail at compilation time, making it obvious immediately, that this will cause issues.

Especially in more complex applications, you want to get an error as soon as you can, so if you can make the compiler throw an error instead of the runtime, the error will be detected earlier.

The user of the library can safeguard this by adding in the appropriate
glib.{Minor,Major}Version checks at runtime, which will sidestep all the build
tag troubles.

While this would alleviate the issue somewhat, there is still a problem: The library user needs to keep track of every single call they use, and which minimum version that requires. Not sure about others, but I tend not to remember which specific version something was introduced in.

The "build tag trouble", while annoying (*), allows us to forcibly set a minimum required version, checked at compile time. This way we, as developers, get feedback from the compiler as soon as we messed up and used a function which is not available yet in our minimum version - regardless of which version we are developing with (which is in many cases NOT the minimum version supported by the application).

(*) => if we keep in mind that deprecated functions should not be removed from compilation in later versions, for obvious reasons. And if you silence the -Wdeprecated warnings it does get better.

[diamondburned]

This would, very likely, silently compile if something is missing. And then panic at runtime.

This is intended; it allows the programmer to code in optional function calls that are only called when the program is running on a newer version. An example of this was the insert-hyphens property in Pango where certain distros were too old to have them.

Especially in more complex applications, you want to get an error as soon as you can, so if you can make the compiler throw an error instead of the runtime, the error will be detected earlier.

It has its cases. This isn't necessarily one of them.

While this would alleviate the issue somewhat, there is still a problem: The library user needs to keep track of every single call they use, and which minimum version that requires.

Yes, this is true. Most programmers won't care enough, and the program will likely crash once it hits that call. This is still a more avoidable problem than having it not build at all, though. One can open an issue to ask for the proper checks instead of telling them to give up.

The "build tag trouble", while annoying (*), allows us to forcibly set a minimum required version, checked at compile time. This way we, as developers, get feedback from the compiler as soon as we messed up and used a function which is not available yet in our minimum version - regardless of which version we are developing with (which is in many cases NOT the minimum version supported by the application).

This is really hard to do properly, both for the programmer and the code generator. The code generation details are mostly implementation-specific so I'll spare you that, but just making multiple files for some tiny one-liner function calls is already a lot of work for the programmer when a simple version check does the job.

Not to mention, package maintainers will have to update the package's build tags every time the upstream GTK package gets updated, which not only is a lot more work, but might also randomly break the package for users who don't always do a full system upgrade. With a simple runtime version check, that doesn't really happen.

[founderio]

I understand you point of view, not having to worry about those tags is certainly a benefit.

There is one alternative solution I can think of.
The main purpose of my question is the error detection at an early point. I assume it would be possible for the generator to provide a list of symbols and when they were introduced - or a small additional tool based on the gir package could be built.
Then, using go/parser or similar, implement a CI tool to check for symbols in the source code which are below or above a certain GTK/Glib/etc release. Unless explicitly specified, this would be the version of the library currently available on the system.

This way both use cases would be possible: Easier compilation without build tags, AND early, static detection of issues with the library version.

What do you think?

[diamondburned]

I think that sounds really complicated to implement. I'm not sure if I should really attempt that.