Not much to say here except respect the coding style of each
library if you are hacking on it. For instance, Glift useses
the "compositing" style design pattern, all member variables
have the form "m_
Do not use them, use three (3) spaces for indentation. If you are using MSVC you need to go to "Tools->options->text editor->c++", check "insert spaces" and set "tab size" and "indent size" to 3. Please do this so that your code looks pretty in MSVC, emacs, vi, etc... ;)
It is preferable to select a CMake "bin" directory that is different from the current source directory, for example "Arbeit/bin". This is where CMake will place the generated files and where build object files will reside. In this directory you will find a Arbeit.sln MSVC project, for example, which loads the entire project, or a Makefile which tells "g++" how to build your applications. This level of organization helps keep the source from getting polluted, which is nice for version controll and stuff like that.
| "Where is the sourece": | {path to..}/arbeit |
| "Where to build binaries": | {path to..}/arbeit/bin |
The only MSVC compiler I am supporting is MSVC.NET 2003 (7.1) or newer. I choose this platform since it is currently the only MS development environment that supports ANSI/ISO C++, ie the standard. Please be aware that some things may not compile correctly without it. Also, much of the future development will encorporate generic programming, see "loki", which definately requires a standard C++ impementation.
If you add a new file: You need to add it to the correct CMakeLists.txt file. Please keep things organized and clean. You also need to add it to the cvs repository, see "CVS notes" in the 3rd party section of this README. Once the file is added and the CMakeLists.txt file is updated, you need to re-run cmake setup to build, platform specifics are below. In fact, any time you make changes to the CMakeLists.txt files, you have to re-run cmake setup. It is a REALY good idea to run cmakesetup or ccmake every time you update from cvs.
The MSVC projects are built around a folder based organization. This requires an extra set of CMake commands for each folder, an example of these commads is documented below. Linux users should still do this to be nice to other MSVC users.
Adding a new folder is simple, just follow these easy steps:Here is an (over-documented) example of the commands that need to reside in the CMakeLists.txt file in order for a folder to appear in MSVC correctly. It is perhaps simplest to copy this block of commads from an existing CMakeLists.txt file and edit the *_SRC, *_FLDR, and *DR variables. This is only an example...
#############################You will see this in the various CMakeLists.txt files without the extra documentation for each step. This only needs to be done once per-folder assuming the files for each folder are collected in individual variables, "NOISE_SRC" in the example above, and the path is saved in another variable, "NDR" in the example.
Adding a project procedes in much the same way. The best thing to do is check out an existing project's CMakeLists.txt file. There are a bunch of things to set: include paths, defines, link paths, and link libraries. Not all are applicable for all project types, for example Libraries dont need to link, so...
You need to install the nvidia linux driver, this involves hacking the etc/XF86conf file, just follow the instructions for driver installation. Please, please, for your own sake read the docs.
Once installed, type "glxinfo" to see a list of extensions and displays supported by the driver, if this is empty, you have not done it right. Here is a small piece of what I get:
>glxinfo
Next you need to copy all of the gl headers to their new home:
cp /usr/share/doc/NVIDIA_GLX-1.0/include/GL/*.h /usr/include/GL
This may have been done by the driver installation, but you should
check. NOTE: You might want to save the old headers (gl.h, glx.h ...etc)
and use sym links to choose which header is currently being used. It
is known that Chromium(TM) only uses the mesa headers, so you might not
want to nuke these if you are using other gl packages.
At some point you will forget the ".." in the previous command, cmake will barf, this is why.) In this example "bin" is in the arbeit tree, if you chose to build elswhere, the ".." becomes the path to the arbeit tree.
Configure the project how you like, if you have a "complete" linux install, you probably already have Qt. If not, you gotta get, either from redhat or from trolltech.com (the make takes hours!).
Now that cmake has configured stuff, successfully you typed 'c' and 'g' in the cmake setup, you build.
from bin:
make
When building your own application from simian lib, be sure you list the libraries in the right order, cuz it matters in linux. You have to have the most "dependent" libraries first in your CMakelists.txt file. You should have a look at the examples for an illustration of this. Here is an example of the link libraries in the right order:
TARGET_LINK_LIBRARIES(basicSimianThe lib lists in "${*}" were defined in the root CMakeLists.txt file in the "arbeit" directory. If you are getting link errors, this is the first place to check, if a lib depends on symbols defined in another lib, the one with the dependency needs to be first in the list.
The executables are located somewhere in the "bin" directory, the structure of this directory should mimic the structure of the root "arbeit" directory. You will find executables in their respective places in the "bin" directory.
Should be it, enjoy.Options have been added to CMake to support enabling the building of Kong (the parallel volume renderer). When you enable BUILD_KONG in CMake you will then have options to use MPI or GM. MPI will be enabled by default. (NOTE: GM is not yet supported.)
If you are adding support for Kong to a shared source code file you should use #ifdef KONG for code that is parallel specific.
These projects must be present to compile, the path to the root project directory can be set as a CMake option. The default assumes you installed them in the root Arbeit directory, but you can put them wherever you like.
That's it, but if you want png support you have to build it, starting with zlib, then png. But that's easy and the source is included. Teem comes with a PNG viewer caled "pv". Here is an example of using pv to view a projection image of some data:
unu project -i teddy.nrrd -a 0 -m max | unu quantize -b 8 | \ unu save -f png | pv -Open it in MSVC and compile, be aware of the nessesary libraries for various build configurations, ie PNG BZIP GZIP etc..., I have included these in the CVS repository, check the lib directory. You will want to have the .dll's in your path or move them to the "windows/system32" directory.
Should just work, compile. You need to either have the lib directory containing the glew32.dll in your path or move glew32.dll and glew32d.dll to the "windows/system32" directory. This is cool if you don't have to change glew, but if you do, like getting a new version, you have to be sure to move the new dll to the system directory every time it changes. If you don't your program will crash. Note: you can also have the dll in the same directory as the .exe and it will always work.
I haven't worked out all the issues here yet. If the glew build ends with an error, check to see if the libGLEW.so built, if it did, you are ok, just move on. If not, well... we have issues. Most likely you got a link error when building "glewinfo" which is extrainious to this project so you can ignore it. I issed a bug with Milan, so maybe this will be fixed by the time you read this.
Ok, the issues below have been resolved, I think, the best thing to do is include QT headers as early as possible. You can often fix problems with misbehaving QT headers by changing the order of the includes. This may not always be possible, however, since glew.h must be included before any other GL files, but likely, glew isn't the deviant. I'm keeping the comments below since it will probably come up again. Try reordering your includes before trying one of the hacks below.
This is because they both define the same thing to be different types in
the "strict" sence. But in reality these are the same types.
Trolltech has a compile definition "-DQT_CLEAN_NAMESPACE" that
fixes this problem. I have added this define to the
"FindQT.cmake" module in the ${QT_DEFINES} cmake
variable. If you are using QT in a project or library, be sure you
have:
ADD_DEFINITIONS( ${QT_DEFINES} )
in your CMakeLists.txt file.
Another issue I had with qt on linux happens when including the qFileDialoge. I get an error around a symbol called "Unsorted" in some "qDlg.h" file. This is because someone else defined this, so it can't possibly be an enum. There are two ways around this, but my choise is to simply test if the symbol is defined and undefine it right before I include the fileDialoge, or any other file that throws the error.
#ifdef UnsortedThis project is under CVS controll at the University of Utah. If you don't have an account there and should have this source contact: Joe Kniss, jmk@cs.utah.edu.
Here is how to check it out:
You may want to put these in a .cshrc or .bashrc file so you don't have to
do this every time you start a new shell.
Here are some {machines} that work:
This just checks your files against the cvs repository and brings in changes from the repository. If there is a "conflict in merge" you have to go into those files and seletct the version of the conflict that is correct, cvs inserts something like:
========>
.. in the code, you need to pick which
