Re: Confusion with Jam, confiigure.ac and configure.ac files

Hi Eric,

I believe you are right on this one.

For OpenGL ES, I do need to link to a different library and different
headers. My reasoning for creating another macro file was that since in the
checkOpenGL.m4 all the checks actually depend on OpenGL being available,
similarly the check for EGL would be dependent on OpenGL ES.

But, I believe your argument makes more sense.  I would stick to having the
checks for EGL and OpenGLES in the same file. Also, 'gles3d' name for the
new renderer sounds perfect to me.

Thanks a lot for your help.

Regards,
Mohit Taneja


On Mon, Jun 24, 2013 at 11:54 PM, Eric Sunshine <[email protected]>wrote:

> On Mon, Jun 24, 2013 at 2:58 PM, Mohit Taneja <[email protected]>
> wrote:
> > Thanks for clarifying that. I guess I should create another macro file
> > checkopengles.m4 to check for the availability of openGL ES and egl, I
> guess
> > that would make more sense to check for the availability for egl with
> > openGLES.
>
> What precisely needs to be detected for OpenGL ES? Do you need only to
> link against a different library? Is there a different header file?
> Different build flags? As a subset of OpenGL, an ES-specific check
> inserted into the existing checkopengl.m4 probably would make sense.
> Naively, I would think that a check for ES would be a minor variant
> among the existing checks. If you can state what sort of check is
> required, and how the build process should be impacted for OpenGL ES,
> that would help determine how best to proceed.
>
> Generally speaking, as Frank (res) mentioned previously, wholesale
> copying of existing OpenGL framework to create an ES variant should be
> avoided. Better is to determine just how OpenGL and OpenGL ES differ
> and then refactor the existing gl3d renderer and openglcommon library
> so that ES support can be grafted in with no (or minimal) duplication
> of code between the existing gl3d and your new gles3d renderer (or
> whatever name you choose). A similar approach is appropriate for the
> build system support: Identify the differences needed for OpenGL ES
> from the existing OpenGL and patch the build system to support ES
> without duplicating code.
>
> > As for now, I guess I will try to compile my code without the
> > check in the Jamfile for egl.
>
> That's a reasonable approach. It's fine to hard-code whatever OpenGL
> ES-specific build gunk you need during development, and then sort it
> out later once the renderer is working.
>
> > I have one more question, how does configure.ac knows that which files
> to
> > check for in the mk/autoconf/ for the tests. So, if I am adding another
> file
> > over there, how would configure.ac know to parse that file too.
>
> As noted above, I don't think you will need a new checkopengles.m4
> file, but the answer to your question is that all *.m4 files are
> available to configure.ac. To generate configure from configure.ac,
> invoke CS/bin/autogen.sh, which will take care of making sure that
> configure.ac has access to all CS/mk/autoconf/*.m4 files.
>
> -- ES
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Crystal-develop mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/crystal-develop
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

_______________________________________________
Crystal-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-develop