G'day, I just tried to install limesuite-20.10.0 on ... FreeBSD walkabout 12.2-STABLE FreeBSD 12.2-STABLE r368123 GENERIC amd64 ... with the octave dependency enabled ... # This file is auto-generated by 'make config'. # Options for limesuite-20.10.0 _OPTIONS_READ=limesuite-20.10.0 _FILE_COMPLETE_OPTIONS_LIST=DOCS GUI OCTAVE QUICKTEST REMOTE SOAPYSDR OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_SET+=GUI OPTIONS_FILE_SET+=OCTAVE OPTIONS_FILE_SET+=QUICKTEST OPTIONS_FILE_SET+=REMOTE OPTIONS_FILE_SET+=SOAPYSDR ... but there remains a line in the PLIST, namely ... lib/octave/5.2.0/site/oct/%%CONFIGURE_TARGET%%/LimeSuite.oct ... which should have been ... lib/octave/5.2.0/site/oct/amd64-portbld-freebsd12.2/LimeSuite.oct ... on my platform. When I manually change that to the correct file, ... make all install package clean ... passes without further issue (final test with my limesdr pending, though). I'm too outdated on porting to propose a proper solution, sorry. 73, Peter.
Whoops, %%OCTAVE_VERSION%% got replaced, but %%CONFIGURE_TARGET%% does not, thank you for the good catch Peter! :-)
Hmm on my 12.2-RELEASE-p1 platform I get stage like this: lib/octave/%%OCTAVE_VERSION%%/site/oct/amd64-portbld-freebsd12.1/LimeSuite.oct and the %%CONFIGURE_TARGET%% does not get into PLIST anymore. When I set by hand: CONFIGURE_TARGET=${HOSTARCH}-portbld-${OPSYS:tl}${OSREL} then files from stage does not match the one from ${CONFIGURE_TARGET}. I did not have that problem several days ago. Did anything change in Ports Tree?
Allright, mystery solved, that full path is provided by the octave-config utility that is part of the Octave suite, this magic path in Stage was taken from a CMAKE and provided by octave-config binary, so we need to obtain it as well in Port Makefile (I found VAR!=exec very handy) and then substitute that full path in a pkg-plist. Now our port fully adapts to existing Octave Suite :-) CONFIGURE_TARGET is not even necessary here and works as expected it just needs an assignment in a way: PLIST_SUB+= CONFIGURE_TARGET=${CONFIGURE_TARGET} Because at the moment we use this port mainly for debugging USB driver problem I have also added and enabled by default DEBUG build option that will generate unstripped binaries ready for easy debug with either gdb or lldb. Feedback and Testing welcome :-) Happy New Year :-)
Created attachment 221279 [details] fixes octave paths and adds debug that is enabled by default. Patch provided by Port Maintainer :-)
I just noticed that octave-config execution should be placed in conditional based on MOCTAVE selecton, will fix that asap, sorry :-)
Hmm putting octave-config in a conditional does not help as make still says that this command does not exist. Will have to see what happens after I build the octave. Any hints welcome ;-)
Hmm the VAR!=command syntax works fine when command exists before make is executed.. but when Octave is not installed before, that evaluates to empty value and gives pkg-plist problem: ===> Building package for limesuite-20.10.0 pkg-static: Unable to access file /usr/ports/comms/limesuite/work/stage/LimeSuite.oct:No such file or directory pkg-static: Unable to access file /usr/ports/comms/limesuite/work/stage/LoadLimeSuite.m:No such file or directory *** Error code 1 Please help @db we are close to a solution but we need something that evaluates after octave is installed.. I have tried $(command) and $$(command) but that does not evaluate well for pkg-plist. Maybe a make target? :-)
A commit references this bug: Author: db Date: Wed Jan 6 18:32:15 UTC 2021 New revision: 560544 URL: https://svnweb.freebsd.org/changeset/ports/560544 Log: fixes octave paths and adds debug that is enabled by default PR: ports/252350 Submitted by: pcc <pcc@gmx.net> Changes: head/comms/limesuite/Makefile head/comms/limesuite/pkg-plist
Thank you DB, however: 1. CONFIGURE_TARGET problem will not be solved this way. There will be `make package` errors. As described above 12.1 value will be enforced on 12.2 system when pkg binary built on 12.1 is used. CMAKE obtains full path from octave-config utility that is already provided on the system. This is why we also need to obtain that full path in Makefile from octave-config that may not yet exist at time of its initial execution so some sort of lazy evaluation needs to take place. 2. Patch was not provided by pcc@gmx.net. 3. We will have to correct that Makefile either in this bug report of in a new one if someone finds what I describe in 1.
===> Building package for limesuite-20.10.0_2 pkg-static: Unable to access file /usr/ports/comms/limesuite/work/stage/usr/local/lib/octave/5.2.0/site/oct/amd64-portbld-freebsd12.2/LimeSuite.oct:No such file or directory *** Error code 1 root@0xCFMX4:/usr/ports/comms/limesuite # ls work/stage/usr/local/lib/octave/5.2.0/site/oct/amd64-portbld-freebsd12.1/LimeSuite.oct work/stage/usr/local/lib/octave/5.2.0/site/oct/amd64-portbld-freebsd12.1/LimeSuite.oct This happens when you build a port on 12.2 when octave is installed from pkg (that uses 12.1). Also installed octave version may be different than actually available in ports. Thus we really need to use octave-config to set the path just as the cmake does :-) I just need to find a way on how to implement it :-)
Chicken egg problem solved :-) The Variable Modifiers section of Make manual page [1] was helpful a lot and gave us the modifier that we exactly need - shell evaluation of already existing variable string :-) We also need to put stuff inside an IF conditional so it only matters when we need it :-) Lets say we have a known command that we need a result from, but only, after all dependencies are installed. Lets store it just as a string and do not execute it (because this program does not yet exist on make call): OCTAVE_OCT_SITE_DIR= (octave-config --oct-site-dir) Then we can use a nice trick to execute that string (":sh" modifier) on its evaluation, and evaluation happens after dependencies are installed and our program is compiled, so we can safely call it now :-) PLIST_SUB+= OCTAVE_OCT_SITE_DIR=${OCTAVE_OCT_SITE_DIR:sh} This way we are not tied to hardcoded Octave from a port tree but we react to actual Octave that is being installed on a system even if it was installed not from ports at all :-) It took some time buy thank you folks for this nice lesson :-) [1] https://www.freebsd.org/cgi/man.cgi?make(1)
Created attachment 221376 [details] port patch that fixed octave hardcode. Port now takes octave paths from octave-config utility after dependency it installed.
Thanks Tomasz, @ll, I now was able to install limesuite-20.10.0_2, so all is fine as far as I can tell. Cheers, Peter. PS. Installed from Makefile: # $FreeBSD: head/comms/limesuite/Makefile 561555 2021-01-14 14:06:27Z pkubaj $
Great to hear! Thank you Peter for finding the bug! :-)
I would prefer to close the issue after patches lands into the Ports upstream though :-) We need to wait a bit for DB she has this on her TODO list. I have no access to Ports repo. If you have write access maybe you could push the changes Peter? :-)
I just got wiki edit access! I invite you to: https://wiki.freebsd.org/hamradio :-)
Today LimeSuite 22.09.0 has been released. Octave problem not merged from this pr is included in update 20.10.0 -> 22.09.0. Feel free to test. Thank you :-) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266307