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