Arch Linux

eschwartz

Fellow

Registered: 2014-08-08

Posts: 4,097

Re: How to install a program from github

If make test fails return success anyway so the package function can be checked.

Can't you just run "makepkg --repackage" to test the package function if the check failed? (or use --nocheck)

The point here would be to not require people to do non-default things.

If the check function is known to fail but not actually be a problem, then refusing to create a package is silly.

The || true, means that the checks actually run so you know it's being issueful, so once the testsuite passes, the workaround can be removed. For pathological cases we do this in the official repos too, although in this case I'd actually (ab)use the "warning()" internal function:

make failing-tests || warning "tests failed"

The warning function makes the error dramatically more noticeable than just ignoring the return code, and despite it being undocumented routines, the worst that can happen if they are removed is that the check function... fails because of the warning instead of the failing tests?

---

Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

progandy

Member

Registered: 2012-05-17

Posts: 5,190

Re: How to install a program from github

Can't you just run "makepkg --repackage" to test the package function if the check failed? (or use --nocheck)

The point here would be to not require people to do non-default things.

Good point, I may have focused too much on the second half of the statement and only thought about testing the PKGBUILD and not the end result given to other people.

If make test fails return success anyway so the package function can be checked.

Last edited by progandy (2018-10-18 22:43:28)

---

| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

funkaddict

Member

Registered: 2018-08-13

Posts: 106

Re: How to install a program from github

Testing openfast looks a bit tricky and appears to involve 2 different methods, check sections 5.2.1 and 5.2.2.

For now I suggest to comment out the check() function with a note that for time being no tests are run during build.

Commenting out the check() function at this point sounds legit. How would you note that there is no test during build? With a prompt in the terminal, or just by use of a comment in the PKGBUILD itself?

There are some dependencies (atleast 2 ) reported missing during build() , check the build log for details.

Sorry if that may sound silly, but where exactly can I find the build log? Edit: Ok, I found it: https://www.archlinux.org/pacman/makepkg.8.html

The point here would be to not require people to do non-default things.

If the check function is known to fail but not actually be a problem, then refusing to create a package is silly.

The || true, means that the checks actually run so you know it's being issueful, so once the testsuite passes, the workaround can be removed. For pathological cases we do this in the official repos too, although in this case I'd actually (ab)use the "warning()" internal function:

make failing-tests || warning "tests failed"

The warning function makes the error dramatically more noticeable than just ignoring the return code, and despite it being undocumented routines, the worst that can happen if they are removed is that the check function... fails because of the warning instead of the failing tests?

So you´ d suggest implementing that like this?

check() {
	cd "$pkgname/build"
	make test
}

So to sum this up here: I am not quite sure if I got the problem by the root. PKGBUILD/makepkg provides a check() function. Most of the PKGBUILDs do not use it, as I have seen from the AUR. However, here for OpenFAST it makes sense to implement the unit test as well as the regression test into the check() function. Besides that, until the check() function works, a workaround could be to just add a message that the check functions fail but the package will be build nevertheless. So OpenFAST can be installed and the test suites can be run seperately?

On https://openfast.readthedocs.io/en/mast … linux.html it says that:

>>CMake options can be configured through command line, e.g.

# to enable Makefile for local building of sphinx-based documentation
cmake .. -DBUILD_DOCUMENTATION:BOOL=ON

# to compile OpenFAST in single precision
cmake .. -DDOUBLE_PRECISION:BOOL=OFF

Does

-DBUILD_TESTING:BOOL=ON

the same as

-DBUILD_TESTING=ON

?

Because on https://openfast.readthedocs.io/en/mast … _test.html it says:

cmake .. -DBUILD_TESTING=ON
make beamdyn_utest

Edit:

From my understanding there are 3 possible ways to proceed:

1) Don´ t implement check() function in the PKGBUILD but leave compiling of the test suite within the PKGBUILD, so the user can run the tests after compiling himself just as described in https://openfast.readthedocs.io/en/mast … _test.html
2) Try to accurateley implement the testing utility as described in the link in the check() function
3) Don´ t even build the testing utilities. I think actually, most of the people who are using OpenFAST never even try to run the testing utilities. It is not the best solution. But for many users this seems "ok"

Last edited by funkaddict (2018-10-19 13:05:43)

eschwartz

Fellow

Registered: 2014-08-08

Posts: 4,097

Re: How to install a program from github

The point here would be to not require people to do non-default things.

If the check function is known to fail but not actually be a problem, then refusing to create a package is silly.

The || true, means that the checks actually run so you know it's being issueful, so once the testsuite passes, the workaround can be removed. For pathological cases we do this in the official repos too, although in this case I'd actually (ab)use the "warning()" internal function:

make failing-tests || warning "tests failed"

The warning function makes the error dramatically more noticeable than just ignoring the return code, and despite it being undocumented routines, the worst that can happen if they are removed is that the check function... fails because of the warning instead of the failing tests?

So you´ d suggest implementing that like this?

check() {
	cd "$pkgname/build"
	make test
}

No, I suggest doing what loqs said:

check() {
	cd "$pkgname/build"
	make test  || true
}

If make test fails return success anyway so the package function can be checked.

So to sum this up here: I am not quite sure if I got the problem by the root. PKGBUILD/makepkg provides a check() function. Most of the PKGBUILDs do not use it, as I have seen from the AUR. However, here for OpenFAST it makes sense to implement the unit test as well as the regression test into the check() function. Besides that, until the check() function works, a workaround could be to just add a message that the check functions fail but the package will be build nevertheless. So OpenFAST can be installed and the test suites can be run seperately?

Most PKGBUILDs don't use it? This is something to ideally fix, but then again, Sturgeon's law applies equally here as with anything else.

ninety percent of everything is crap

Also, tests that are run separately will be forgotten about... so running it but ignoring the failures might be seen as useless, but I see it as useful because the user will by default see the errors and become aware that there's the possibility of issues.

On https://openfast.readthedocs.io/en/mast … linux.html it says that:

>>CMake options can be configured through command line, e.g.

# to enable Makefile for local building of sphinx-based documentation
cmake .. -DBUILD_DOCUMENTATION:BOOL=ON

# to compile OpenFAST in single precision
cmake .. -DDOUBLE_PRECISION:BOOL=OFF

Does

-DBUILD_TESTING:BOOL=ON

the same as

-DBUILD_TESTING=ON

?

Because on https://openfast.readthedocs.io/en/mast … _test.html it says:

cmake .. -DBUILD_TESTING=ON
make beamdyn_utest

The ":BOOL" bit doesn't actually do a single thing. Or, to be more specific, here is the documentation on it: https://cmake.org/cmake/help/latest/pro … /TYPE.html

All it does is provide hinting for the CMake *GUI*, so that it knows what type of selection dialog to offer you.S

Last edited by eschwartz (2018-10-19 13:10:12)

---

Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

vap0rtranz

Member

From: Chicago, USA, Earth, Sol

Registered: 2019-03-06

Posts: 6

Re: How to install a program from github

I realize this thread has gone stale but it wasn't marked SOLVED so I wanted to share what I did because there were unanswered questions here and from the OP's other thread.  (My selfish purpose here is to understand how makepkg/PKGBUILD can build from source, safely, like in a chroot; and this thread made the process look complex compared to traditional make && make install in chroot). 

I'm a n00b to Arch, and do see value in makepkg/PKGBUILD, but like most abstractions there may be issues with the basics, so I went back to basics and built the OP's source, OpenFAST (whatever that is), with the old make && make install method but inside a chroot.  What worked for me was:

mkdir chroot
CHROOT=$HOME/dev/chroot
mkarchroot $CHROOT/root base-devel
arch-nspawn $CHROOT/root pacman -Syu
arch-nspawn $CHROOT/root pacman -S cmake lapacke gcc-fortran
sudo arch-chroot $CHROOT/root

Skipping some (hopefully obvious) details of getting the OpenFAST source into the chroot, then:

cd $HOME/OpenFAST/build/
cmake ../
make

Which looks to have built the binaries:

Scanning dependencies of target openfast
[ 99%] Building Fortran object glue-codes/openfast/CMakeFiles/openfast.dir/src/FAST_Prog.f90.o
[100%] Linking Fortran executable openfast
[100%] Built target openfast

I didn't install because I've no desire to run the program and we probably all understand the install moves the binaries around the filesystem. 

So for Arch, these utilities are unique:

mkarchroot
arch-nspawn
makepkg

Am I missing anything else that's unique?

And next steps would be translating from how this source is traditionally built (cmake && make && make install) into how makepkg expects to build from source?  or take the binaries built the classic way, host the binaries for public download, and have the PKGBUILD pull them down for installs?

Last edited by vap0rtranz (2019-03-06 14:35:40)

HalosGhost

Forum Moderator

From: Twin Cities, MN

Registered: 2012-06-22

Posts: 2,092

Website

Re: How to install a program from github

First off, welcome to the BBS!

I realize this thread has gone stale but[…]

When you say things like this in your head, it's usually a good queue to double-check if you should continue.

In this case, the thread has gone nearly half a year without a post; it's probably time to let it lie. As per usual, if you wish to have what appears to be a related conversation, opening a new thread and linking to the old for context is a reasonable choice.

Furthermore, the makepkg documentation on the wiki and in the man pages should be more than enough to walk you through things like this. Particularly, if you are looking to build a package in a clean chroot, there's a wiki page on that already (which covers the use of the tools you mention): https://wiki.archlinux.org/index.php/De … ean_chroot

Closing.

All the best,

-HG

---

Code of Conduct