Package Details: ampi-openmpi 7.0.0-1

Git Clone URL: (read-only, click to copy)
Package Base: ampi-openmpi
Description: Adaptive Message Passing Interface, OpenMPI backend
Upstream URL:
Licenses: custom:Charm++/Converse License
Submitter: marmistrz
Maintainer: carlosal1015
Last Packager: carlosal1015
Votes: 1
Popularity: 0.000000
First Submitted: 2019-05-12 09:00 (UTC)
Last Updated: 2021-10-30 16:32 (UTC)

Latest Comments

carlosal1015 commented on 2022-01-17 02:16 (UTC)

Hi @hexd, thanks for the detailed explanation, totally agree for change the installation way only with cmake, like this.

I'll check out other charm's packages on repology for inspiration, I will read the CMakeLists.txt in detail. I hope to get it soon.

hexd commented on 2022-01-16 22:21 (UTC) (edited on 2022-01-17 04:37 (UTC) by hexd)

@carlosal1015, I wasn't able to open your testing runner link, HTTP 404 error.

The issue has to do with the custom build process performed by the shell script found upstream, as it "switches" depending on whether the build environment has cmake installed or not. The buildold script is the one it runs when cmake isn't found, and this shell script properly works, creating the install target for make. The default alternative when it detects cmake doesn't create this target, breaking the packaging process (yes, the error in this case happens on package(), not on build(), but when you try to run it again without --force then it'll break on build() with the configure step message I've sent, because the src directory is somehow "dirty"; with --force you don't need to erase it manually). Just try to install cmake (e.g. by inserting it on makedepends) and you'll see makepkg breaking like it did here.

I've already modified the PKGBUILD here to install this package locally (I've just replaced ./build [...] by .buildold [...] --force). I actually did that before reporting it here. I believe the relevant parts of the log you requested are already in my previous message, and there's nothing special/customized that could make any difference in this case (apart from the fact that I have cmake installed).

Perhaps you can also try the default cmake-style installation instead of relying on make install. That means using cmake --install <BUILD_DIRECTORY> --prefix <PREFIX> or something similar, but I haven't tried this. Probably the cmake-only approach is better in the sense that the "old" in buildold suggests it will no longer exist in the future. Either way, temporarily setting makedepends=(gcc-fortran cmake) will let you test the behavior in environments with cmake installed.

carlosal1015 commented on 2022-01-06 02:57 (UTC) (edited on 2022-01-09 15:11 (UTC) by carlosal1015)

Edited 2022-01-09: We could suggest this line for clean build directory.

Hi @hexd, thanks for reporting.

I would like to know if maybe the file /etc/makepkg.conf has some customization w.r.t the runner that I am testing.

I will follow the for verification.

I am not sure if is running over x86-64 or another architecture. I understand that build() function pass, but package() function failed. I would like to look the full log, when success or failed. (Hint $ makepkg -s 2>&1 | tee log.txt).

hexd commented on 2022-01-04 02:17 (UTC)

Either the makedepends should include the cmake (and something else should be done for installing), or ./buildold should be called instead of ./build (that's the simplest solution).

With cmake installed, it builds, but on packaging makepkg complains and fails with:

make: *** No rule to make target 'install'.  Stop.

And running makepkg again doesn't resume the process, on the contrary: it breaks on trying to build the already built stuff, requiring a manual cleanup for building it again:

The configure step has already taken place for the specified build.
To attempt a partial rebuild, run 'make' in "mpi-linux-x86_64".
To remove the existing data and reconfigure, run this script again with --force.

Perhaps the --force should always be there (in the ./build or ./buildold command) to avoid requiring a manual intervention (and perhaps to avoid breaking AUR package managers).

The same is happening with charm++-openmpi.