search

Perl-GPU / OpenGL-GLUT

Other
1 stars 4 forks source link

release OpenGL::GLUT soon to CPAN #5

Closed devel-chm closed 7 years ago

devel-chm commented 7 years ago

The current git repo version of OpenGL::GLUT appears to be working. In the interest of accelerating the development of OpenGL::Modern, I would like to make a first official release of OpenGL::GLUT today and sooner if possible. :-)

I think other than some clean up or creation of Changes, READM.md updates, and the like, we should be good to go. Note: since OpenGL never had a perl package for OpenGL::GLUT, this new module will only be loaded if the user explicitly adds it to their code. Legacay, all OpenGL uses will still be supported.

devel-chm commented 7 years ago

I've just pushed a CPAN developers "alpha" release to check that the CPAN and CPAN Testers side of things work. The distribution could use a Changes file and some better/any documentation. I would like to have an official release today.

devel-chm commented 7 years ago

At the moment, GLUT.pm has no pod content.

devel-chm commented 7 years ago

CPAN testers results look ok. Once the git history is re-attached and some sort of pod is put in place, plan for an official release no later than 2017-03-04.

wchristian commented 7 years ago

I think a good step to do before that would be to delete more of the unneeded stuff. Can you do a second pass of just deleting files that you know are unnecessary? Then i can have another overview and a bit of a think on what to document.

devel-chm commented 7 years ago

I've deleted all I think can safely be done without breaking back compatibility---including that this should build and install if OpenGL did too. A side effect of my cleaning out the non-GLUT stuff was that I removed alll the POD.

Given that OpenGL never had much docs to begin with, we don't need much but probably an explanation of how using OpenGL::GLUT would work with OpenGL and OpenGL::Modern. I think I've removed direct access to the non-GLUT stuff in OpenGL::GLUT so just documenting the GLUT/FreeGLUT bindings and maybe an example of use would be enough.

I would like to remove the binary-blob pseudo-install of FreeGLUT for windows and go to something like an Alien::FreeGLUT. However, in the interest of not breaking things, I'm leaving it in for now.

devel-chm commented 7 years ago

@wchristian:

I've deleted all I think can safely be done without breaking back compatibility---including that this should build and install if OpenGL did too. This is why the Makefile.PL build process and some "extra" files are still present. The goal is to provide back compatibility support for OpenGL::Modern.

wchristian commented 7 years ago

@devel-chm I think there was some kinda typo with the last message.

wchristian commented 7 years ago

Ah thanks for the fix-up of that message, and alright, since you're confident i'll work out sketch of POD.

devel-chm commented 7 years ago

I'm confident that OpenGL::Modern will be significantly improved over OpenGL both in level of support for OpenGL APIs and with better software engineering.

sisyphus commented 7 years ago

Do we really want to prohibit building against static freeglut library on Windows ? On Windows, I build against the static library, but I had to patch include/GL/freeglut_std.h in 0.70_01: freeglut_std.h.diff.txt

That just reinstates that section of code to what it was in OpenGL-0.67_04.

Doesn't really bother me if I have to continually patch that file - it's a fairly simple alteration, so it would only be a fairly mild annoyance for me.

It's really just a question of whether the excluding of the build against the static library constitutes an improvement. To me, it seems like a backwards step, but maybe there are considerations here of which I'm unaware.

Cheers, Rob

devel-chm commented 7 years ago

@sisyphus: seems reasonable to include this. After all, this is sort of a clean start.

wchristian commented 7 years ago

Please note that the relevant bit was changed in https://github.com/devel-chm/OpenGL-GLUT/commit/7ff4d7d604f5deb4aad47aa9dc5befb3320e6bf9 wherein i pull in stuff from http://www.transmissionzero.co.uk/software/freeglut-devel/

Possibly you'd want to check it for updates or alternatives.

sisyphus commented 7 years ago

From: Christian Walde (Mithaldu) Sent: Thursday, March 02, 2017 11:25 PM To: devel-chm/OpenGL-GLUT Cc: sisyphus ; Mention Subject: Re: [devel-chm/OpenGL-GLUT] release OpenGL::GLUT soon to CPAN (#5)

Please note that the relevant bit was changed in 7ff4d7d wherein i pull in stuff from http://www.transmissionzero.co.uk/software/freeglut-devel/

Possibly you'd want to check it for updates or alternatives.

Ooops ... forgot to preview, and stuffed up the formatting of my reply via the web interface, so I'll see if reply via email works any better:

In freeglut_std.h, both 3.0.0 and today's svn zip (rev 1792) I see:

/ Windows static library /

ifdef FREEGLUT_STATIC

define FGAPI

define FGAPIENTRY

    /* Link with Win32 static freeglut lib */

if FREEGLUT_LIB_PRAGMAS

ifdef NDEBUG

pragma comment (lib, "freeglut_static.lib")

else

pragma comment (lib, "freeglut_staticd.lib")

endif

endif

That is slightly different to what we now have in the freeglut_std.h that's part of OpenGL-GLUT. (What we now have in this section of freeglut_std.h is the same as appears in the freeglut-2.8.1 source of freeglut_std.h.) I'm not bothered by the difference - I gather it relates to building against static MSVC-built libs.

Cheers, Rob

wchristian commented 7 years ago

Alright, so regarding static linking it doesn't matter to you whether we use freeglut 3 or manually patch it. I'll try and see if an update to 3 has things still working smoothly.

wchristian commented 7 years ago

This indicates it should go smoothly: http://upstream.rosalinux.ru/versions/freeglut.html

wchristian commented 7 years ago

@sisyphus Turns out that you were looking at the MinGW archive, while the one i used to upgrade back then was the MSVC one. Reason for that being that the MSVC one does contain .lib files, while the MinGW one contains .a files (despite freeglut_std.h talking about .lib files).

Please have a look and advise how i should progress on that:

sisyphus commented 7 years ago

From: Christian Walde (Mithaldu) Sent: Friday, March 03, 2017 11:37 PM To: devel-chm/OpenGL-GLUT Cc: sisyphus ; Mention Subject: Re: [devel-chm/OpenGL-GLUT] release OpenGL::GLUT soon to CPAN (#5)

Alright, so regarding static linking it doesn't matter to you whether we use freeglut 3 or manually patch it. I'll try and see if an update to 3 has things still working smoothly.

I'm not entirely sure about what "matters" to me, and what doesn't :-)

It does matter to me that building against a static freeglut library works.

However, I build against a mingw-built static libglut.a, and I assume that those #pragma statements (which specifically refer to static libraries as ".lib", and therefore not mingw-built) apply only to msvc-built static libraries. I therefore (rightly or wrongly) believe that the content (or even the existence) of those #pragma statements is irrelevant to my needs. (But I'm not suggesting that it's only my needs that should be considered here.)

Hell, I don't even know that it's necessary to #define FGAPI and to #define FGAPIENTRY. (I mean ... I expect it is necessary that those #defines be made, but it's not something I've specifically tested :-)

So ... if it turns out there's something more that I ought to test, just let me know and I'll certainly oblige.

Christian, the Windows perls that I routinely use are all self-built using a mingw compiler. They are not actually "Strawberry Perl', but they are binary-compatible with Strawberry Perl (and ActivePerl), and essentially the same. Strawberry builds against a dynamic freeglut library, whereas I prefer to build against a static freeglut library.

Cheers, Rob

wchristian commented 7 years ago

Right, here's my problem: I dunno shit about C. I have no idea what you're talking about there or what your actual concern is or what the right path to resolution is. You're absolutely in the position of authority here and i'm just providing info on what i did in the past and what i found by reading around, without actually understanding what your goal here is.

That said:

However, I build against a mingw-built static libglut.a, and I assume that those #pragma statements (which specifically refer to static libraries as ".lib", and therefore not mingw-built) apply only to msvc-built static libraries.

In the MSVC zip archive those are purposefully stripped out. They're only left in the MinGW one.

devel-chm commented 7 years ago

@sisyphus Rob, I have to admit I'm not sure what the outcome of this discussion re static/dynamic builds. I would like to recommend that the fix for that be addressed after the first official OpenGL;:GLUT release. Would that be acceptable to you?

For context: I'm in a rush to get OpenGL::GLUT, OpenGL::GLU, and OpenGL::Array out so that OpenGL::Modern can be finished and usable. :-)

devel-chm commented 7 years ago

@wchristian Any pod for OpenGL::GLUT? I would like to push the official release soon. Maybe we only need a basic list of the functions and constants in the module and a list of the options for use-age: :all, :something,...

wchristian commented 7 years ago

Not today, i'll write it up tomorrow.

devel-chm commented 7 years ago

I've just released OpenGL::GLUT 0.71 to CPAN with a basic POD. It will need updating but the functionality appears to be good enough for OpenGL::Modern implementation to continue.

sisyphus commented 7 years ago

From: devel-chm Sent: Saturday, March 04, 2017 2:17 AM To: devel-chm/OpenGL-GLUT Cc: sisyphus ; Mention Subject: Re: [devel-chm/OpenGL-GLUT] release OpenGL::GLUT soon to CPAN (#5)

@sisyphus Rob, I have to admit I'm not sure what the outcome of this discussion re static/dynamic builds. I would like to recommend that the fix for that be addressed after the first official OpenGL;:GLUT release. Would that be acceptable to you?

Sure.

Cheers, Rob

sisyphus commented 7 years ago

From: Christian Walde (Mithaldu)

However, I build against a mingw-built static libglut.a, and I assume that those #pragma statements (which specifically refer to static libraries as ".lib", and therefore not mingw-built) apply only to msvc-built static libraries. In the MSVC zip archive those are purposefully stripped out. They're only left in the MinGW one.

And that seems to be the only difference between the two renditions of freeglut_std.h.

The github OpenGL-GLUT rendition of freeglut_std.h (with the 'static' capability reinstated) is the same as the rendition that's in freeglut-2.8.1 official source. And that should be fine - for as long as we're building OpenGL-GLUT against freeglut-2.8.1, at least.

With freeglut-3.0.0, freeglut_std.h underwent some code changes - and I don't know if that will pose problems when we build our current OpenGL-GLUT against freeglut-3.0.0. For the moment, Strawberry uses freeglut-2.8.1 and so do I. This is something I could take a look at this week. I recall that there were problems with the tessellation example script with the old OpenGL when it was built against freeglut-3.0.0.

Do any of you guys have any experience of whether tessellation.pl works ok using a github OpenGL-GLUT that was built against freeglut-3.0.0 ?

Cheers, Rob

sisyphus commented 7 years ago

It dawned on me finally that the files in the include/GL/ folder are intended to be used only when building against the dll provided in the FreeGLUT folder, and should be irrelevant to both mine and strawberry's builds. We should be accessing those files from our freeglut source instead.

Having realized that, I've taken appropriate steps (via my own non-portable hacks) to ensure that I don't load those files. Basically, I've just appropriated the hack that kmx used for the same purpose (ie to define IS_STRAWBERRY in a couple of places).

The contents of that include/GL folder are no longer an issue for me.

I'll close this in the belief that there's nothing else to be covered here. Apologies if I'm breaking some sort of protocol by doing that .... I won't take offense if someone wants to re-open it.

Cheers, Rob