single Makefile.inc and build.sh for scotch and ptscotch

[minrk]

only include deviations from default in platform Makefiles

build number is bumped because -DSCOTCH_PTHREAD is restored, which had been removed.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[dalcinl]

Sorry about the removal of -DSCOTCH_PTHREAD . This bug slipped from my ongoing work on ptscotch. For the parallel variant, IMHO we should not use that flag. Too bad that scotch only allows compile-time configuration of threads.

[dalcinl]

@minrk Either on Linux or macOS we use GNU Make. Then, why don't we just provide Makefile.inc and inside it do:

ifeq ($(shell uname ),Linux)
    ABC = xyz
else
    ABC = xyz
endif

[dalcinl]

Maybe we are doing something wrong here? Isn't conda build supposed to pass -Wl,-headerpad_max_install_names in the LDFLAGS environ var?

[dalcinl]

Maybe we should do LDFLAGS := ${LDFLAGS} -L${PREFIX}/lib -lz -lm -pthread?

[dalcinl]

Are you sure all makefiles are properly written to support parallel builds?

[minrk]

I've just tested and they certainly aren't! Removed.

[dalcinl]

I think you hae to do it this way:

CCS = ${CC}
CCP = ${CCS}
CCD = ${CCP}

Then, in build.sh, and only for ptscotch, export CCP=mpicc.

[dalcinl]

@minrk I think you have parts of #16. The install step for ptscotch has to be different, otherwise you install both the parallel and sequential headers/libraries. That does not look right.

[dalcinl]

We need -fPIC both in Linux and macOS. Otherwise we may not be able to build a sharedlib PETSc.

[dalcinl]

Maybe just seeting CLIBFLAGS = -fPIC in Makefile.inc is good enough?

[dalcinl]

@minrk Looking at your comment in #16, you are definitely right, ptscotch does not actually depend on scotch. The problem is that when you build ptscotch, you also get the scotch libraries and headers in the install tree. So I expect that some third-party libraries (that's the case of PETSc) would expect both the scotch and ptscotch variants at configure time. Making ptscotch depend on scotch would make things simpler. But of course we can just update the PETSc recipe to depend on both scotch and ptscotch.

[dalcinl]

We also have a problem with the esmumps.h header file, there is no ptesmumps.h header, but we have libesmumps.a vs libptesmumps.a. Which package should own esmumps.h ?

[minrk]

Should the ptscotch install exclude the scotch libraries? I would think that installing ptscotch and scotch would be mutually exclusive, especially since the scotch build flags should be different depending on whether it's used for ptscotch or not (e.g. -DSCOTCH_PTHREAD for serial, but not for parallel)

[dalcinl]

Yes, for sure the ptscotch install exclude the scotch libraries. But our build.sh script was not doing that, we don't make install/ptinstall, just cp ... $PREFIX/<include,bin,lib> !. My changes in #16 fix that issue.

[dalcinl]

Just to make things clear: Right now, the ptscotch package in anaconda.org contains sequential and parallel libraries, with the exceptions of libesmumps.a. That was the cause of the previous failure in conda-forge/petsc-feedstock#18 (now it is passing, after a quick test adding both scotch and ptscotch as dependencies).

However, installing both scotch and ptscotch together in a conda environment should work, all libraries have different names, the same for headers (with the exception of esmumps.h).

[dalcinl]

@minrk Oh! Hold on, ptscotch.h includes scotch.h !!