Following the build instructions

git clone --recurse-submodules https://github.com/fangq/iso2mesh.git
cd iso2mesh
rm -rf bin/.mex bin/*.exe
cd tools
make clean
make

Current CGAL-4.14 requires a change in

iso2mesh/tools/cgalmesh/mesh_polyhedral_domain.cpp

CGAL/AABB_intersections.h -> CGAL/intersections.h

I have asked upstream about another build problem (w/ the meshfix tool) that doesn't appear to be CGAL related:

https://groups.google.com/forum/#!topic/iso2mesh-users/W71rP4iMVr8

hi @mhough, I reactivated my fedora account (keep inactive for almost 10 years), and joined the neurofedora sig.

I also installed a fc30 virtual machine on my linux system, and made some progress on packaging iso2mesh. After a few minor changes and a few packages, I was able to compile/run iso2mesh on fc30 using the provided octave 4.4.1.

A screenshot of the working iso2mesh can be found at the bottom.

A few steps to make this work:

1. needed build dependencies:
   sudo dnf install cmake CGAL-devel SuperLU SuperLU-devel blas-static tetgen
2. I updated iso2mesh cgalmesh source code to use the new intersections.h header file
   https://github.com/fangq/iso2mesh/commit/6b687fcd9533f8557a31ce9f4867bdbd1b5c1009
3. I updated cork's Makefile to use gcc/g++ instead of clang; I also updated meshfix to include slu_cdefs.h with the right path, see
   https://github.com/fangq/iso2mesh/commit/24736f5a5c39c2a970bff8565f3be1335d213d93

after that, all binaries can be compiled and generated under iso2mesh/bin. I only compile for tetgen1.5 from git, and rely on system to provide tetgen (which on fc30 is the same as tetgen1.5 - iso2mesh previously assumes tetgen is for tetgen1.4.3, but this is ok).

After that, majority of iso2mesh functions will be readily usable in octave. I tested most of demo scripts, about 70% worked, most of the failures were related to the missing of octave-image. I would prefer not to place octave-image as a dependency to iso2mesh, and only ask users to install when then need those functions.

Let me know if you are interested in giving this a try. simply

git clone --recursive https://github.com/fangq/iso2mesh.git 

should grab the latest updated files.

let me know if you have new problems.

@mhough and @ankursinha, I'd like to get some help from you guys on finishing the spec file for packaging iso2mesh

here is my current version
https://github.com/fangq/fedorapkg/blob/iso2mesh/octave-iso2mesh.spec

I got everything working (compilation) until %octave_pkg_build in the %build section, and the error was it looks for

../rpmbuild/BUILD/iso2mesh-1.9.1/build/iso2mesh-1.9.1-x86_64-redhat-linux-gnu-api-v52.tar.gz

but only

../rpmbuild/BUILD/iso2mesh-1.9.1/build/iso2mesh-1.9.1-any-none.tar.gz

the above suffix is only generated when buildarch is set to noarch, but this is not the case in my spec file.

I tracked this down to macros.octave, and it did choose the 1st branch where buildarch is not noarch
https://github.com/OpenMandrivaAssociation/octave/blob/e218aa61608e632f8871800113c65718389d9229/octave.macros#L30-L34

but somehow, pkg install command still produces the any-non.tar.gz tarball.

do you spot anything in my spec file that might cause this issue?

thanks, if I get this around, should be able to finish the spec file today and submit for a new package.

just to clarify - what actually went wrong was this line in the macros.octave file

print(rpm.expand("octave -H -q --no-window-system --no-site-file --eval 'pkg build -verbose -nodeps %{_builddir}/%{buildsubdir} "..octpkg_tarfile).."'\\n")

because it did not generate the right suffix, the if/else branch got the correct suffix, but failed afterwards as the desired suffixed tarball was not generated in the above pkg build line.

Hey @fangq,

So great to have you in NeuroFedora! I am at NYC Neuromodulation right now but will look at this soon. ROAST developers are here and they are built on top of iso2mesh BTW.

@mhough, glad to hear from you. did you mean TOAST from UCL?
http://web4.cs.ucl.ac.uk/research/vis/toast/links.html

@mhough and @ankursinha after several hours of reading/testing, I moved this forward a little bit

it turns out that the issue is related to this redhat bug

https://bugzilla.redhat.com/show_bug.cgi?id=1413450

that the %octave_pkg_install function in macros.octave (part of octave-devel) was written in shell script but %octave_pkg_build was written in lua, and the octave_tar_suffix defined in pkg_build is not passed on to pkg_install.

from what I can see (through many tests), the current octave_pkg_install can only handle buildarch=noarch, but not mex files with buildarch!=noarch.

To get around this issue, I found a solution from this link

https://pagure.io/koji/issue/19

where I can set BuildArch to noarch, and set ExclusiveArch to desired arch to build. With this change

https://github.com/fangq/fedorapkg/commit/97a1b1ba0f252ce7137ae13aa30bf3dcd5580287

I was able to pass the previous error. I got a new error which is related to the .debug file generated from the compilation stage.

==================
[Update]: it looks like octave_pkg_build did pass on the correct octave_tar_suffix to octave_pkg_install. It must be somewhere the octave pkg command failed to get the correct suffix and produced the -any-none.tar.gz tarball.

done!

new package submitted at https://bugzilla.redhat.com/show_bug.cgi?id=1758626

for some reason, I can't link this pagure url in bugzilla. added @mhough and @ankursinha to the tracker. will send a review request in the mailing list.