[Crystal-develop] Adding Link Libraries to the Build system

[Mohit Taneja]

Hi,

After a lot of fun learning (a.k.a banging my head on my desk) with the
XWindowing system, EGL and mesa, I believe I am at a good point with the
code for the EGL plugin.

But before, I could test it with my system, I need some help with linking
the mesa libraries for egl and gles2.0 with the build system for
Crystalspace3D. I am using the libraries libgles2-mesa and libegl-mesa to
test the egl plugin, also I had installed their dev versions to include the
header files for the same libraries. I am ust having a little bit of a hard
time trying to figure out how to add these libraries to the linker for the
build. @Eric : Any suggestions.

Also, I have a small question regarding committing code to svn, should I be
committing code which is not in a perfect working condition also, or should
I only make big chunks of commit of only the working code. As of now, I am
following the latter system. Any comments on the same ?

Regards,
Mohit Taneja

[res]

Post by Mohit Taneja
But before, I could test it with my system, I need some help with
linking the mesa libraries for egl and gles2.0 with the build system for
Crystalspace3D. I am using the libraries libgles2-mesa and libegl-mesa
to test the egl plugin, also I had installed their dev versions to
include the header files for the same libraries. I am ust having a
little bit of a hard time trying to figure out how to add these

Via “an “ExternalLibs” statement in the Jamfile.

Best if there were already some configure checks for EGL and GLES.

A lazier way to use ExternalLibs would be to just write the right-named
variables with the appropriate values to Jamconfig.
How it works you can see with basically every 3rd-party lib CS uses,
e.g. PNG.

Post by Mohit Taneja
Also, I have a small question regarding committing code to svn, should I
be committing code which is not in a perfect working condition also, or
should I only make big chunks of commit of only the working code. As of
now, I am following the latter system. Any comments on the same ?

“Commit early, commit often”.
With that approach, it's possible to monitor code as it evolves. This is
useful in the presence as you can get feedback on your changes quicker
and you can act accordingly – e.g. if some piece of code is likely to
make problems on some platform or down the line it's easier to fix it
while it's still “fresh” and not much other stuff possibly depends on
it. (Providing an intermediate state of code also makes it easier to
provide assistance, which might help avoiding those head-shaped dents in
the desk in the future.)
Apart from that, smaller changesets are generally easier to read,
understand and review. Ideally, there's one “logical“ change or step per
commit.

The code committed don't has to be perfect, but it should at least
compile on your platform, and not crash right away or be otherwise
knowingly catastrophically broken.

-f.r.