Horizontal

[mantaraya36]

The build system now has a different philosophy. It will not fail on missing dependencies, but will not build modules (or functions) instead. This will hopefully encourage separate "allo" modules that bring in optional functionality with additional dependencies. This work can eventually lead to a more stripped down "allocore" and moving some stuff to optional modules. This of course would break existing code, but could lead to a stabilization of the API for AlloSystem version 1.0.

[DrewRWx]

OS: OS X 10.9

The generated Makefile tries to build alloglv and alloutil despite cmake determining that they can't be built. (Additionally, during this edge case install of alloglv, ALLOGLV_INCLUDE_DIR was not set and _alloGLV/alControlGLV.hpp couldn't be found in the include path. )

Also, are there any designs for suggesting dependencies? For example, (working from a clean MacPorts install) it took some deduction to figure out that the linker errors generated from the run.sh script were referring to glew and libportaudio when compiling allocore/examples/graphics/frontBack.cpp .

It looks like parts of cmake code, like link flags for luajit and using flags.txt, are in a code block dependent on BUILD_EXAMPLES . Is that intentional? Those seem useful for general builds or run.sh useage.

Finally, passing -Wno-deprecated-declarations to the compiler will suppress the GLUT warnings on OS X.

[mantaraya36]

Thanks for the careful review.

I fixed the issue with alloGLV, but could not reproduce the problem with alloutil. The only dependency for alloutil is either lua or luajit (luajit takes precedence), and if neither is available, alloutil is not built (This is working fine for me, tested with no lua, only lua, only luajit and both, and the behavior is correct, maybe it's an issue with how macports packages lua?)

I've now added the compile option for GLUT (only added for release builds, you will still see the warnings on debug builds).

The flags for the linker on OS X, were there already in cmake_modules/CMakeRunTargets.cmake, but I've made a small change to make sure they're picked up (haven't tested, though, so if you can confirm they are added, it would be great).

The problem you mention about having problems finding the dependencies from the linker errors, is one of the main issues that needs to be solved when taking this approach. Right now I'm inclined to autogenerate a cpp file with function stubs that print on the terminal that the functions are not available due to particular missing dependencies. Any ideas?

[DrewRWx]

My issue with alloGLV is fixed and I think my issue with alloutil is part of the new issue quoted below. This error disappears if lines 47-60 in CMakeLists.txt are commented out.

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
ALLOGLV_LINK_LIBRARIES
    linked by target "allocore_examples_graphics_frontBack" in directory /Users/dtemp/Development/MAT/brancher/AlloSystem
ALLOUTIL_LINK_LIBRARIES
    linked by target "allocore_examples_graphics_frontBack" in directory /Users/dtemp/Development/MAT/brancher/AlloSystem

The GLUT warning flag worked perfectly!

I was wondering why using those linker flags, such as for luajit, in CMakeLists.txt depends on BUILD_EXAMPLES at line 86. It seems to be set false by default.

Also, it looks like NO_EXAMPLES is only used in allovsr. Should that variable be merged with BUILD_EXAMPLES ?

I'm not sure what to do on dependency finding.

Finally, cmake (3.0) emitted a lot of warnings: https://gist.github.com/DrewRWx/51f552594556aefead4d .

[mantaraya36]

These should fix your issues.

We'll get to the cmake 3.0 warnings in due time...

[mantaraya36]

About the linker flags, they are only needed when building applications that link to alloutil, so they are located in the application building facilities in CMakeRunTargets.cmake. Are they not working for you?

Maybe it needs to be documented somewhere that you need these flags if you plan to use alloutil.

Cheers, Andrés

[DrewRWx]

-Wno-dev would suppress those cmake 3.0 warnings.

NO_EXAMPLES is still in README.md.

Nitpick: There are two build messages in _zeroconfmodule.

If I'm reading that right, then lines 90-162 in CMakeLists.txt are just throwing everything and the kitchen sink at making sure that all of the examples in AlloSystem are built?

[mantaraya36]

Hi,

On Sat, Jun 28, 2014 at 3:13 PM, Drew Waranis notifications@github.com wrote:

-Wno-dev would suppress those cmake 3.0 warnings.

I prefer to leave these warnings on. When it comes time to move to cmake 3.0, it might be important to deal with them.

NO_EXAMPLES is still in README.md.

Nitpick: There are two build messages in _zeroconfmodule.

The two small issues are fixed.

If I'm reading that right, then lines 90-162 in CMakeLists.txt are just throwing everything and the kitchen sink at making sure that all of the examples in AlloSystem are built?

Yes, we need to bring everything in, as there is no easy way of knowing what each example requires. Are you talking specifically about lines 135-140?

—

Reply to this email directly or view it on GitHub https://github.com/AlloSphere-Research-Group/AlloSystem/pull/33#issuecomment-47437317 .

[DrewRWx]

I figured it would be easier for users not to see cmake specific errors that they have no control over. It can be flipped off when doing cmake work.

I was more wondering about the flags.txt files and the alloutil linker flags, but now everything makes sense!

On Mon, Jun 30, 2014 at 1:54 PM, Andres Cabrera notifications@github.com wrote:

Hi,

On Sat, Jun 28, 2014 at 3:13 PM, Drew Waranis notifications@github.com wrote:

-Wno-dev would suppress those cmake 3.0 warnings.

I prefer to leave these warnings on. When it comes time to move to cmake 3.0, it might be important to deal with them.

NO_EXAMPLES is still in README.md.

Nitpick: There are two build messages in _zeroconfmodule.

The two small issues are fixed.

If I'm reading that right, then lines 90-162 in CMakeLists.txt are just throwing everything and the kitchen sink at making sure that all of the examples in AlloSystem are built?

Yes, we need to bring everything in, as there is no easy way of knowing what each example requires. Are you talking specifically about lines 135-140?

—

Reply to this email directly or view it on GitHub < https://github.com/AlloSphere-Research-Group/AlloSystem/pull/33#issuecomment-47437317>

.

— Reply to this email directly or view it on GitHub https://github.com/AlloSphere-Research-Group/AlloSystem/pull/33#issuecomment-47585695 .