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

Eric Sunshine <[email protected]> Mon, 24 Jun 2013 23:54:07 -0400
Newsgroups gmane.comp.graphics.crystalspace.devel
Message-ID <CAPig+cTdKPu_8pbqSiDDcTcnVWrnNY0m8xD=k2cOJ_OUDv-2eQ@mail.gmail.com>
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