A few patches to fix current trunk

[tom fogal-3]

Nigel Stewart <nstewart@...> writes:
> So it seems to be that glew_utils.h is needed unless there is a
> broader decision to discontinue GLEW_SPLIT_SOURCE mode.
>
> My inclination to leave this one alone.  But I personally don't see
> much need for GLEW_SPLIT_SOURCE.

Ahh, I missed that initially, sorry.  I agree ignoring it for now seems
prudent.

-tom

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[tom fogal-3]

Current trunk is failing to build due to recent extensions changes.
Attached are two patches which correct this issue and one which fixes
an oversight in a patch I sent earlier.

  0001 -- A patch I sent earlier was missing a "\n" in a debug print.
          This fixes that.
  0002 -- A recent change to a registry spec has confused GLEWs parsing
          code.  Please review *carefully*, I'm a bit worried about
          this one!
  0003 -- NVIDIA's video_capture.txt extension is breaking the build
          due to parse issues.  I didn't look deeply, but my guess is
          that function prototypes are using glX types either without
          defining them or without including the necessary X/glX
          header.

Is there any sort of GLEW nightly builder?  I feel like I keep putting
down and picking up GLEW, and extension parsing changes bite/confuse
me every time.  It would be nice if I got a mail when the trunk starts
failing; I spent some time today before I realized that some patches I
had locally weren't at fault here.

Cheers,

-tom


From e161bae5debb81f55cc2f763906f9df12c76ccfb Mon Sep 17 00:00:00 2001
From: Tom Fogal <tfogal@...>
Date: Wed, 4 Nov 2009 20:37:26 -0700
Subject: [PATCH 1/3] Add missing \n on error print.

---
 auto/bin/make.pl |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/auto/bin/make.pl b/auto/bin/make.pl
index b97b0a4..a20fdf1 100755
--- a/auto/bin/make.pl
+++ b/auto/bin/make.pl
@@ -132,7 +132,7 @@ sub output_tokens($$)
         print map { &{$fnc}($_, $tbl->{$_}) } sort { hex ${$tbl}{$a} <=> hex ${$tbl}{$b} } keys %{$tbl};
         print "\n";
     } else {
-        print STDERR "no keys in table!";
+        print STDERR "no keys in table!\n";
     }
 }
 
--
1.6.3.3


From 7031df943c28e3ce9d9627ac02e1cae6702d87d7 Mon Sep 17 00:00:00 2001
From: Tom Fogal <tfogal@...>
Date: Wed, 4 Nov 2009 20:37:48 -0700
Subject: [PATCH 2/3] Fix GL_EXT_direct_state_access parsing.

A recent modification added the paragraph:

    <OpenGL 3.0: New indexed generic queries (added for indexed texture
    state) replace "v" for "i_v" to name and add "uint index" parameter
    (to identify the texture unit) after state name parameters (if any)
    and before state value parameters>

unfortunately this isn't getting collapsed into one line.  Thus,
the regex to specifically deal with these direct_state_access
"comments" fails, because the opening "<" and closing ">" are on
different lines.

This removes all lines that begin with "<" or end with ">".
---
 auto/bin/parse_spec.pl |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/auto/bin/parse_spec.pl b/auto/bin/parse_spec.pl
index 445bdf3..cbac643 100755
--- a/auto/bin/parse_spec.pl
+++ b/auto/bin/parse_spec.pl
@@ -139,7 +139,10 @@ sub normalize_prototype
 {
     local $_ = join(" ", @_);
     s/\s+/ /g;                # multiple whitespace -> single space
-    s/\<.*\>//g;              # remove <comments> from direct state access extension
+    s/^\s*//g;                # remove all WS from beginning of the line
+    s/\s*$//g;                # remove all WS from the end of the line
+    s/^\<.*//g;               # remove <comments> from direct
+    s/.*\>$//g;               # state access extension.
     s/\s*\(\s*/ \(/;          # exactly one space before ( and none after
     s/\s*\)\s*/\)/;           # no after before or after )
     s/\s*\*([a-zA-Z])/\* $1/; # "* identifier"
--
1.6.3.3


From cc68b4b86a9f6105b730b1fae83b7c2a3bed1ce8 Mon Sep 17 00:00:00 2001
From: Tom Fogal <tfogal@...>
Date: Wed, 4 Nov 2009 22:02:50 -0700
Subject: [PATCH 3/3] Blacklist NVIDIA's video capture extension.

Seems to be causing parse issues.
---
 auto/blacklist |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/auto/blacklist b/auto/blacklist
index 6cd0e11..e001284 100644
--- a/auto/blacklist
+++ b/auto/blacklist
@@ -12,3 +12,4 @@ SGIX/video_source.txt
 SGIX/hyperpipe_group.txt
 OES/OES_fixed_point.txt
 OES/OES_query_matrix.txt
+NV/video_capture.txt
--
1.6.3.3


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

Tom,

>   0001 -- A patch I sent earlier was missing a "\n" in a debug print.
>           This fixes that.

Looks fine to me.  I'll put it in today.

>   0002 -- A recent change to a registry spec has confused GLEWs parsing
>           code.  Please review *carefully*, I'm a bit worried about
>           this one!

Ouch.  I'll go ask Mark Kilgard if there is an established
convention for what GL_EXT_direct_state_access is trying
to convey.

>   0003 -- NVIDIA's video_capture.txt extension is breaking the build
>           due to parse issues.  I didn't look deeply, but my guess is
>           that function prototypes are using glX types either without
>           defining them or without including the necessary X/glX
>           header.

I'm fine with skipping NV_video_capture, and I'll put the change in.
But I'll also see if there is an appropriate upstream fix.

> Is there any sort of GLEW nightly builder?  I feel like I keep putting
> down and picking up GLEW, and extension parsing changes bite/confuse
> me every time.

I understand, I'm tempted to set that up internally here - except that
then I'd be catching _all_ of the breaks.  One practical issue is that
I wouldn't want to be downloading the entire extension repository
all the time - I wonder if wget or curl can mirror that in an
efficient manner.

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

>>   0003 -- NVIDIA's video_capture.txt extension is breaking the build
>>           due to parse issues.
>
> I'm fine with skipping NV_video_capture, and I'll put the change in.
> But I'll also see if there is an appropriate upstream fix.

The problem with NV_video_capture is that it mixes GL, WGL and GLX
functions and enums into the one spec, which I guess would require some
extra handling by GLEW.

http://www.opengl.org/registry/specs/NV/video_capture.txt

So for now, let's just leave it out of GLEW.

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

> 2. glew_utils.c doesn't seem to be used ever. Historical artifact?
> Remove it.

There appears to be a glew_utils.h to go along with it.

auto/Makefile has targets for glew_def.c, glew_init.c,
glew_str.c - do we need those targets anymore?

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

>>   0002 -- A recent change to a registry spec has confused GLEWs parsing
>>           code.  Please review *carefully*, I'm a bit worried about
>>           this one!

Tom,

I propose this alternative patch for the handling of
GL_EXT_direct_state_access handling.  The problem seems
to be that parse_spec is reading line-by-line and attempting
to convert the accumulated lines into a function prototype.
In the situation that a comment line ended in )
normalize_prototype would fail to strip away the (unfinished)
comment.

- Nigel

Index: auto/bin/parse_spec.pl
===================================================================
--- auto/bin/parse_spec.pl (revision 562)
+++ auto/bin/parse_spec.pl (working copy)
@@ -140,6 +140,7 @@
      local $_ = join(" ", @_);
      s/\s+/ /g;                # multiple whitespace -> single space
      s/\<.*\>//g;              # remove <comments> from direct state access extension
+    s/\<.*$//g;               # remove incomplete <comments> from direct state access extension
      s/\s*\(\s*/ \(/;          # exactly one space before ( and none after
      s/\s*\)\s*/\)/;           # no after before or after )
      s/\s*\*([a-zA-Z])/\* $1/; # "* identifier"

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[tom fogal-3]

Nigel Stewart <nstewart@...> writes:

> >>   0002 -- A recent change to a registry spec has confused GLEWs parsing
> >>           code.  Please review *carefully*, I'm a bit worried about
> >>           this one!
>
> Tom,
>
> I propose this alternative patch for the handling of
> GL_EXT_direct_state_access handling.  The problem seems to be that
> parse_spec is reading line-by-line and attempting to convert the
> accumulated lines into a function prototype.  In the situation that a
> comment line ended in ) normalize_prototype would fail to strip away
> the (unfinished) comment.

Yeah.  It would be best (IMHO) if parse_spec could read by "chunk",
e.g. by paragraph, but I'm not sure I'd trust a regexp that coalesced
multiple lines; I think it'd end up putting some functions on the same
lines as explanatory text.  Or, at least it would if I wrote it ;)
Perhaps there's someone with more regexp-fu listening in... ?

Anyway, I haven't tested the patch below but it looks like this would
work, and it would certainly clip less than what I sent before.  LGTM.

-tom

> Index: auto/bin/parse_spec.pl
> ===================================================================
> --- auto/bin/parse_spec.pl (revision 562)
> +++ auto/bin/parse_spec.pl (working copy)
> @@ -140,6 +140,7 @@
>       local $_ = join(" ", @_);
>       s/\s+/ /g;                # multiple whitespace -> single space
>       s/\<.*\>//g;              # remove <comments> from direct state access
> extension
> +    s/\<.*$//g;               # remove incomplete <comments> from direct sta
> te access extension
>       s/\s*\(\s*/ \(/;          # exactly one space before ( and none after
>       s/\s*\)\s*/\)/;           # no after before or after )
>       s/\s*\*([a-zA-Z])/\* $1/; # "* identifier"

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

> auto/Makefile has targets for glew_def.c, glew_init.c,
> glew_str.c - do we need those targets anymore?

Tom,

Looking at auto/Makefile, there seems to be support for a
GLEW_SPLIT_SOURCE mode (disabled by default) that generates
glew_def.c, glew_init.c and glew_str.c.

So it seems to be that glew_utils.h is needed unless there
is a broader decision to discontinue GLEW_SPLIT_SOURCE mode.

My inclination to leave this one alone.  But I personally
don't see much need for GLEW_SPLIT_SOURCE.

The only mention I can find of it on the web is:
http://glew.sourceforge.net/log.html

...
1.3.3 [05-16-05]
     * New feature:
           o Code generation option to split source into multiple files
...

- Nigel

...
ifeq (yes,$(GLEW_SPLIT_SOURCE))
S.TARGETS = \
         $(S.DEST)/glew_def.c \
         $(S.DEST)/glew_init.c \
         $(S.DEST)/glew_str.c \
         $(S.DEST)/glewinfo.c
else
S.TARGETS = \
         $(S.DEST)/glew.c \
         $(S.DEST)/glewinfo.c
endif
...

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

> Anyway, I haven't tested the patch below but it looks like this would
> work, and it would certainly clip less than what I sent before.  LGTM.

Done deal.
Committed revision 563.

- Nigel

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

Tom,

> 3. GLU isn't needed to use GLEW. Further, we should not force
> clients to utilize or even have GLU. Don't include it in our
> headers, but add the include into visualinfo.c to make sure it
> still compiles.

In a way, I see your point about GLU.

But -

1. They may be a significant number of applications using GLEW
    which will no longer build.

2. It is convenient to have GLEW as the "OpenGL universe" including
    core, extensions, and GLU.

I don't favour making this change, unless there is widespread
support/passion/agreement.  I would be more inclined to support
a patch that introduced a #ifdef which would be optional, and
allow glu.h to be ignored.

Cheers,

- Nigel

--------------------------


diff --git a/auto/src/glew_head.h b/auto/src/glew_head.h
index cffa472..ae5ecfe 100644
--- a/auto/src/glew_head.h
+++ b/auto/src/glew_head.h
@@ -1053,13 +1053,3 @@ GLAPI void GLAPIENTRY glViewport (GLint x, GLint y, GLsizei width, GLsizei heigh
  #define GLEW_VERSION_1_1 GLEW_GET_VAR(__GLEW_VERSION_1_1)

  #endif /* GL_VERSION_1_1 */
-
-/* ---------------------------------- GLU ---------------------------------- */
-
-/* this is where we can safely include GLU */
-#if defined(__APPLE__) && defined(__MACH__)
-#include <OpenGL/glu.h>
-#else
-#include <GL/glu.h>
-#endif
-


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[Nigel Stewart-2]

Tom,

> 1. Build the binaries from the object files instead of the .c files.

Committed as revision 564.

Cheers,

- Nigel


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders

[tom fogal-3]

Nigel Stewart <nstewart@...> writes:

> > 3. GLU isn't needed to use GLEW. Further, we should not force
> > clients to utilize or even have GLU. Don't include it in our
> > headers, but add the include into visualinfo.c to make sure it
> > still compiles.
>
> In a way, I see your point about GLU.
>
> But -
>
> 1. They may be a significant number of applications using GLEW
>     which will no longer build.

Sure.

For the dynamic loading patch, there's a minor API change (and, I
haven't verified but probably significant ABI change), so maybe this
should be considered in that context when we post that patch to the ML.

I also note that some apps, e.g. Google's Chrome, have modified GLEW so
that it will not import GLU [1,2].

> 2. It is convenient to have GLEW as the "OpenGL universe" including
>    core, extensions, and GLU.

We still have e.g. glxew and wglew header files, so there was some
desire at some point that users could use GL functions without having
to pull in GL-windowing code.  I view GLU in the same light.

I'd bet some distros would like to remove GLU as a build-dep from their
GLEW packages, too.

> I don't favour making this change, unless there is widespread
> support/passion/agreement.  I would be more inclined to support a
> patch that introduced a #ifdef which would be optional, and allow
> glu.h to be ignored.

Yeah, that's what Chrome's GLEW does actually.

Anyway, let's drop the issue for now and I'll raise it again when
posting the dynamic loading patch.

-tom

[1]
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/glew/include/GL/glew.h?view=log
[2]
http://src.chromium.org/viewvc/chrome/trunk/src/third_party/glew/include/GL/glew.h?r1=27404&r2=28062
[] .. I'll also note that they've implemented what Jianrong and I
   have done, not just months after I announced it here but months
   after we'd already been using it ourselves.  So they obviously
   didn't even google around before going off and implementing it
   themselves... grr.  I'll be sure to prod them about being more
   community-oriented in the future, eventually..

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
glew-coders mailing list
glew-coders@...
https://lists.sourceforge.net/lists/listinfo/glew-coders