Hi Paul, Paul Garlick <pgarl...@tourbillion-technology.com> skribis:
>> I think it might make sense to create a new “simulation” module, and >> eventually move OpenCascade there as well, WDYT? >> > Sure. I will create a new module and put the OpenFOAM package > definition in there as the first one. Sounds good. >> Some comments: >> >> >> > >> > + (build-system trivial-build-system) >> > > >> >> >> Did you consider using ‘gnu-build-system’? I think this would save >> quite a few lines corresponding to the initial setup (set-paths, unpack, >> patch-shebang, etc.), and also ensure that the final phases (strip, >> compress-documentation, etc.) are run. In addition you wouldn’t need to >> list all the usual build inputs (GCC, Coreutils, Make, etc.). WDYT? >> > > I did consider both options, removing and modifying stages in the gnu- > build-system or starting from scratch with the trivial-build-system. I > can give the gnu-build-system option a go, reverting to the trivial- > build-system if the new attempt proves too troublesome. With ‘gnu-build-system’ you’ll have to replace/remove some of the phases, but hopefully it’ll be less troublesome nonetheless. > One aspect I will need to investigate in the gnu-build-system is using > the "./Allwmake" command to trigger the build process. In OpenFOAM, > wmake is short for "wrapped-make" and the package has its own > configuration step. In brief, it has its own sequence and does not > follow the standard "./configure && make && make install" steps. > Using the trivial-build-system the patch-shebang section is indeed a > little extended. I found this was necessary to avoid a failure of the > patch-shebang command using a simple 'find-files "."' from top-level > directory. There is a scenario where sub-directories named '0', in the > 'tutorials' directory, identified by the find-files command, being > passed to 'patch-shebang', which should only receive files, not > directories. This causes 'patch-shebang' to stop and the build fails. ‘find-files’ excludes directories by default, so it’s a little surprising. Anyway, we can surely find a way to work around the problem. >> > >> > + ) >> > + ) >> > + ) >> > + ) >> > > >> >> >> Please listen to what ‘guix lint’ has to say about these. :-) >> > > Interestingly, 'guix lint' let me get away with this without making > comment. However, I shall condense things accordingly in the new > patch. Oh indeed, until now it would only scan 60 lines from the start of the definition. Fixed! >> What about wrapping the resulting binaries so that they have >> ‘FOAM_INST_DIR’ set to %output? >> >> > > In fact, FOAM_INST_DIR is used in multiple places to navigate around > the installed files (not just the binaries), so I think this variable > may need to remain available as is. OK, though it would be good to make it work out-of-the-box when FOAM_INST_DIR is undefined. >> You could make it “if true”, thereby avoiding the need to define >> $READLINE_ROOT. >> >> > > Could you elaborate on this idea a little? At the moment the test is > "if file exists". I was thinking about doing something like this: -if [ -f /usr/include/readline/readline.h ] +if true and thus we wouldn’t need to define READLINE_ROOT, IIUC. HTH, Ludo’.
