Makefile/build process

[daurnimator]

The build process is full of odd practices

• use prefix (mostly to replace GRDIR)
• prefer OS provided libraries (e.g. use -lz instead of bundling zlib)
• prefer dynamic linking over static
• don't install libraries from each other. e.g. make -C lib/gr install shouldn't install gks.
• have separate install targets for C library vs python library vs julia library
• use $(MAKE) if you need to call out to another makefile

[danielkaiser]

We are closing this issue due to inactivity. Please reopen the issue and let us know if its cause still persists with the current version of GR.

[daurnimator]

I don't think any of the issues I mentioned here have been fixed.

[FlorianRhiem]

Hey, the build system is something we've been working on over time, though the progress has been rather slow as the build system usually worked well enough and other bugs or features were more pressing or useful. I recently refactored our thirdparty builds for the self-contained build style, unifying build systems there and moving to PREFIX. Something similar still needs to be done for the main Makefiles (and their MinGW counterparts) and things like $(MAKE) are part of that, as well as proper dependency target handling and configuration. Someone else is also working on a CMake based build as an alternative to the current Makefiles for gr, gks, gr3 and the plugins, and I expect that to be ready soon, with less "historically grown" qualities to it. :)

We've also split up the Julia and Python wrappers into seperate repositories. The wrappers will only install the GR runtime if no pre-existing runtime (with the required minimum version) is found locally.

The way we deal with thirdparty dependencies, offering bundled versions and using static libraries for those, comes down to design choices though:

• The reason we aren't relying on system libraries for the "core" dependencies (zlib, libpng, libjpeg, freetype, qhull) and offer a self-contained build that uses bundled libraries for most other dependencies (excluding things like Qt, wx, X11) is that we try to support a large variety of systems and while we do need to somewhat differentiate between linux distributions with our binaries, doing it this way makes it far easier for these builds to work in varying environments, with as little requirements for the runtime environment as possible.

• The reason for using static libraries is related to this, it is also done to reduce dependencies at runtime and make deployment easier, particularly for our Python and Julia wrappers. You can still use shared libraries if you don't use the self-contained build, just not for our "core" dependencies. Though we are considering making that optional as well, lettings users use either system dependencies only or bundled libraries only.