moab.make.in

[Nico Schlömer]

The file moab.make.in contains

MOAB_INCLUDES = -I@abs_srcdir@/src \
                -I@abs_builddir@/src \
                -I@abs_srcdir@/src/oldinc \
                -I@abs_srcdir@/src/parallel \
                -I@abs_builddir@/src/parallel \
                -I@abs_srcdir@/src/LocalDiscretization \
                -I@abs_srcdir@/src/RefineMesh

Those are all directories that refer to the source tree, i.e., locations that you don't want to see in the export files.

[Vijay M]

This is slightly tricky because when we install, there is a post-install the replaces the variable MOAB_INCLUDES with

MOAB_INCLUDES = -I${prefix}/include

This is certainly true for the autotools route but I'm unsure if we are doing anything similar for CMake. Either way, this happens only during install.

So the real question is whether we technically do an install when building for debian ? If not, we may have to add hardcoded paths such as the following during a post-processing step.

MOAB_INCLUDES = -I/usr}/include
MOAB_LIBDIR = /usr/lib/x86_64-linux-gnu

It might still be a bug to not do the above during CMake install, if we are not doing this already. I'll check.

[Vijay M]

I think something like this would work.

http://stackoverflow.com/questions/9998679/is-it-possible-to-add-post-install-commands-to-top-level-makefile-generated-by-c

[Nico Schlömer]

there is a post-install the replaces the variable MOAB_INCLUDES

Why not set it right in the first place then?

[Vijay M]

Because the user may not install the code just yet but still may want to run examples from in-source. If you look, the examples/makefile.in only includes moab.make.in and iMesh-Defs.inc, which should work for both in-source and installed libs use cases.

[Nico Schlömer]

If I understand correctly, the examples are not built by default, but you still want to allow the user to build them, using the headers from the source directory and the libraries from the build directory.

I haven't seen such a setup before. Trying to use the same export files for these kind of builds and the actual installed MOAB seems like a bit of a long shot to me. I see why messing around (aka replacing strings) in the export files is necessary.

An approach that I'm seeing more often is that examples are build alongside libraries and tests in the build process, and just not installed. Oftentimes, tests are identified with examples. The advantages I see here are that

• no tinkering with the export files are required and that
• build failures in the examples are caught immediately.

Perhaps this would be something to consider.

[Vijay M]

True. Perhaps we should force that users always install first before using the examples ? In which case, the export files can directly point to DESTDIR.

Compiling examples as part of the library means that they would use autotools Makefiles, which I didn't want. I want to use pure GNU makefiles with just an include for flags/libs so that examples and user code can be compiled seamlessly. I also intend to re-organize the examples folder and so will start a discussion related to this soon.

[Nico Schlömer]

True. Perhaps we should force that users always install first before using the examples ?

Or have it installed in some other way, perhaps by their sysadmin or by apt-get install moab. The examples would then serve as a sanity test for the installation, which I find is not unreasonable. The examples could be supplied with a README that says:

1. Make sure to install MOAB
2. copy this folder somewhere
3. do make, cmake ../ or whatever
4. ...

[Paul Wilson]

I think this issues was exacerbated in d3b39af , at least with the Mesquite additions to iMesh-Defs.inc. These are not updated/replaced at install time.

In any case, there must be a way to remove all the references to the build directories rather than just overwriting the variables...

[Vijay M]

Not sure why you point to that hash as a problem. I agree that appending variables to the end is just confusing. I'll create a branch that just overwrites this file during installation to a prefix.

On a broader note, I think if we force our users to install first before using examples, half of the complexity won't exist. Only when a user wants to compile/link against the build directory does the complication arise. Perhaps its time to torch this path to simplify maintenance.

[Paul Wilson]

I just grabbed that hash because blame showed that a lot of additional entries appeared with that one (it was perhaps better referenced as an example rather than a culprit).

context: I dug into it because PyTAPS (which we still depend upon until we have time to refactor everything to pymoab) does some naive parsing of iMesh-Defs.inc that ignores conditionals. Therefore PyTAPS only fails in MOAB 5.0 because of the MSB_LIB entries that are defined but never used in most sane build processes if HAVE_MESQUITE is negative. This string does get parsed and block PyTAPS from building as part of it's setup.py.

Changing from build to install directories won't help PyTAPS, nor should we do anything to make PyTAPS work, nor should we change PyTAPS - we should and will update PyNE to stop relying on PyTAPS and instead rely on pymoab.

[Paul Wilson]

bumping this issues since I am noticing it again in my current cleanup