On Mon, 2022-06-13 at 16:38 -0700, Dan Crocker wrote:
>
> -Built the generic pulseview
> -Ran new_driver in the libsigrok/build directory as you suggested
> -Applied the patch created by this new_driver script as instructed in
> the README created:
> 'cd /some/path/libsigrok'
> 'git am /some/place/0001-raspberrypi-pico-Initial-driver-skeleton.patch'
> Of course, I used the actual paths for my environment :).
> After this, I did have source files for the raspberry pi pico in the
> "hardware" directory (in a directory called raspberrypi-pico)
> -Edited the original build script to remove the rm of the $BUILDDIR
> and the git clones. [ ... ]
This sequence is ... unexpected. Who suggested it? Should be
fixed to do something normal instead.
Running the script which executes a standard sequence once is
fine. Modifying the script to not restart from scratch but to
continue with previous build output is fine, too. But two things
are bothering me.
The new_driver script does not magically create a driver for you.
If it could the list of supported devices would be longer. :-]
What the script creates is a skeleton for a driver which a
developer needs to fill in and get to work with a specific
device. That part is missing in the above list of steps.
The other issue is that manually patching the source to introduce
the non-operational skeleton, and then to manually copy in more
file content, which is not under version control, and is getting
lost in iterations, is tedious and non-reproducable. Would have
expected some addition of another remote, checkout of that
branch, and be done with two additional commands and no other
manual work involved.
Another option would be to globally change the common prefix for
repos that are being fetched from at the start of the script, in
the tunables section. To not get the sigrok.org master but
somebody else's code base instead. Consistently as it is kept
there in a set of repos that belong to each other, similar to
what sigrok.org provides. The script is prepared to do that, it's
not (by design) prepared to run an arbitrary combination of
unrelated changes from different repos. Notice that this remote
repo might as well reside on your disk. Nobody said that a
network needs to be involved.
I'm aware this is not your fault Dan for trying to follow these
instructions. It's the instructions that are weird and un-gitty
(if that is a word).
> Here's an example of a section of the script that makes libserialport:
>
> # libserialport
> #$GIT_CLONE $REPO_BASE/libserialport
> cd libserialport
> ./autogen.sh
> rm -rf build
> mkdir build
> cd build
> ../configure $C
> $SB make $PARALLEL $V
> make install $V
> cd ../..
>
> The rest of the sections are similar.
Yes this is what you typically would do without the script. The
script just spells out that typical flow, assuming that none of
it was done before and can be skipped since it executed before.
(And the script can assume that, because it starts by design from
a fresh and empty directory.)
> Note that do get this error at the end of the build:
>
> ----
> Running tests...
> Test project /Users/dan/sigrok-util/cross-compile/macosx/build/pulseview/build
> Start 1: test
> 1/1 Test #1: test .............................***Failed 16.15 sec
>
> 0% tests passed, 1 tests failed out of 1
>
> Total Test time (real) = 16.16 sec
>
> The following tests FAILED:
> 1 - test (Failed)
> Errors while running CTest
> Output from these tests are in:
> /Users/dan/sigrok-util/cross-compile/macosx/build/pulseview/build/Testing/Temporary/LastTest.log
> Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
> make: *** [test] Error 8
Have you eyeballed that output? The screen output references a
logfile which has more details on the failed test.
One of the pulseview tests is known to depend on the platform,
and fails when floating point numbers get rounded to the other
end compared to what most other platforms do. Can't tell from
first hand experience, but thought that macos was one of the
platforms that were affected. Could be that, a last digit of a
conversion result flipping and not matching the expectation.
Instead of wading through the logfile, another option is to ask
ctest what the test was, and rerun it, and see the coloured
output on screen. May speed up your finding the spot. ctest can
list the set of available tests, show the command that would
execute at higher verbosity levels, and you can manually run the
command from the prompt. Or you find a way of running the exe
under ctest _and_ have the verbosity raised, to have your
attention attracted to the spot of interest.
$ ctest -N
$ ctest -N -V
$ ctest -VV
I think cmake generated Makefiles (which pulseview probably uses
when built with the script) support this invocation, which
explains how "make test" is related to ctest(1) outside of
guessing it from screen output.
$ make VERBOSE=1 test (or any other target)
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
