Closed jlots closed 1 year ago
Look at the makefile and how I've had to link sdl, doesn't look like your doing that.
It would be nice to add in the README what changes are needed on the .gpr file of the project that uses this via alire. Currently, doing 'alr with sdlada' works fine, but you get the undefined references as noted above when trying to actually call anything in SDL. From memory, this is quite normal when grabbing a library intended for use in C/C++, and I need to add ("-lSDL2main", "-lSDL2", "-lSDL2_image");
compile switches one way or another in your .gpr file.
Found it! @jlots add this:
package Linker is
for Switches ("Ada") use ("-lSDL2main", "-lSDL2", "-lSDL2_image");
end Linker;
And to your compile flags, add the output from sdl2-config --cflags
on your machine, e.g.:
package Compiler is
for Default_Switches ("Ada") use
("-I/usr/include/SDL2", "-D_REENTRANT") & -- add this line
Compile_Checks_Switches &
Build_Switches &
Runtime_Checks_Switches &
Style_Checks_Switches &
Contracts_Switches &
("-gnatw.X", -- Disable warnings for No_Exception_Propagation
"-gnatQ"); -- Don't quit. Generate ALI and tree files even if illegalities
end Compiler;
(the hint was in sdlada's build/gnat/makefile line 29)
@TamaMcGlinn add where? There are several Compiler and Linker packages across SDLAda in various gpr files and none of them look like any of these.
He means put them in your project's gpr file. They are in the makefile as SDL2 was a little bit tricky to make work entirely portably, i.e. with just "make," with gpr files.
You might find using alire easier.
I did use alire but just as described in the comments, all kinds of linker errors arise. And it's not at all obvious why "my project's gpr file" should have anything like these, especially when using alire.
Anyway, to be frank, there is ASFML and that really just works:tm:. That's enough for me.
SDL2 has a sdl2-config executable which you have to use to be portable to get the cflags and the ldflags to add to your project (SDL3 doesn't have this), as stated above, this is all in the makefile in the build/gnat directory. We cannot call this from within the gpr file. Alire can, see the sdl's toml file as I call the makefile from there.
Currently, doing 'alr with sdlada' works fine, but you get the undefined references as noted above when trying to actually call anything in SDL.
As previously stated, that's exactly right. alr build
won't work, once you actually need to link any SDL calls. But anyway.
Added this to the README with a pointer to the makefile. I don't think it's too difficult to add this to your gprbuild command line and you can always script it.
Some people wouldn't check how to release a library that works out of the box.
SFML doesn't have a script required to build properly whereby flags can change even on the same platform. SDL does have this, it's called sdl2-config. And there's no excuse not for checking how to build something.
There is no excuse for not providing working artifacts and then trying to downplay it as if it was the duty of the user to tinker with the internals of a package.
There's no excuse for being rude either.
Okay, one final, patient attempt...
Is there any particular reason you are assuming that a released library (any released library) shouldn't just work without ad-hoc tinkering of the internal building process? For what it's worth, I quickly checked a Raku binding library and a Pascal binding library to the very same SDL2 library and nothing like that was needed so it doesn't seem like it's a quintessential property of SDL2.
We may disagree about a certain named reason but without any such reason, this whole apparent "meh, you can find out the problem and fix it for yourself" mentality is simply unsuited for package release and maintenance. We may call it "rude" if you fancy that word but one thing is sure: something isn't released and maintained software just because it appears over the internet encoupled with some license. In this case, it may actually be better if it's apparent that it's not released with the intention to make it actually work as much as possible, rather than trying to normalize semi-functional releases.
Let's get one thing straight, READ THIS and THIS because you don't seem to have bothered to find out.
I was advised to "release" this on alire for the crate competition as things were not going well for me, it could've helped financially. I released it for Linux as that is my current platform. Others did work to get it to work on Windows and Mac.
For the last (quite a few) months, I've not felt like doing any programming especially Ada. I've only come back here to comment after some time away from here to point out some facts to you. So, sorry my situation has got in the way of you using something I don't get paid to work on.
because you don't seem to have bothered to find out.
You seem to have weird expectations of people who really only came to install a library. If it's relevant for the software, make it apparent here.
I never thought Github was for blogging but if this gives me any sort of credibility in your eyes: I moved away from antidepressants earlier this year, then my grandma died while I was changing workplaces, which prompted my mother to move to her dad so I suddenly found myself pretty much alone in a new life situation and this was about my life when I wrote that comment. I've been having panic attacks during the day even at home recently, and I've waken up to feeling my consciousness falling to pieces, trying to formulate sentences in my head just to somehow convince myself that I'm not completely losing my mind.
So there you have it. One can, and I think clearly should, put these things aside when participating in FOSS development.
I don't want to spill fuel on the fire but I have technical objections as well. Let me just say that I think the whole FOSS "business" is rather an escape route where one can feel useful, pleasing themselves and often others as well, not a place to dump personal problems, like it was something nice to share with strangers.
Trying to compile a separate project that depends on SDLAda. I have followed the directions in README.md and installed the static library at $HOME/opt. The gpr located at $HOME/opt/share/gpr is accessible and shows in GPS as a dependency. The tests in the SDLAda library build and execute correctly.
When I try to take a test and compile it as part of a separate project, I get many linking errors: