You are not logged in.

#51 2018-10-18 21:40:32

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 2,379

Re: How to install a program from github

progandy wrote:
loqs wrote:

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)

Offline

#52 2018-10-18 22:41:11

progandy
Member
Registered: 2012-05-17
Posts: 3,134

Re: How to install a program from github

eschwartz wrote:
progandy wrote:

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.

loqs wrote:

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 ' |

Offline

#53 2018-10-19 10:41:12

funkaddict
Member
Registered: 2018-08-13
Posts: 37

Re: How to install a program from github

Lone_Wolf wrote:

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?

Lone_Wolf wrote:

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


eschwartz wrote:

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)

Offline

#54 2018-10-19 13:08:47

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 2,379

Re: How to install a program from github

funkaddict wrote:
eschwartz wrote:

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:

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

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

funkaddict wrote:

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.

Sturgeon's law wrote:

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.

funkaddict wrote:

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)

Offline

Board footer

Powered by FluxBB