-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate placeholder C functions for outdated libraries #24
Comments
There is a side effect to this though: 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.
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 |
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
It has its cases. This isn't necessarily one of them.
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.
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. |
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. 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? |
I think that sounds really complicated to implement. I'm not sure if I should really attempt that. |
gotk4 should generate C functions in its own header file that panics when called
just so it could be compiled on systems with any outdated libraries.
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 buildtag troubles.
This issue deprecates #14.
The text was updated successfully, but these errors were encountered: