Bug 252350 - comms/limesuite: Octave dependency does not replace %%CONFIGURE_TARGET%% in PLIST
Summary: comms/limesuite: Octave dependency does not replace %%CONFIGURE_TARGET%% in P...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Diane Bruce
Depends on:
Reported: 2021-01-02 16:44 UTC by pcc
Modified: 2021-01-10 21:18 UTC (History)
2 users (show)

See Also:
tomek: maintainer-feedback+

fixes octave paths and adds debug that is enabled by default. (2.26 KB, patch)
2021-01-05 03:29 UTC, Tomasz "CeDeROM" CEDRO
no flags Details | Diff
port patch that fixed octave hardcode. (1.69 KB, patch)
2021-01-08 06:29 UTC, Tomasz "CeDeROM" CEDRO
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description pcc 2021-01-02 16:44:13 UTC

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

... but there remains a line in the PLIST, namely ...


... which should have been ...


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


Comment 1 Tomasz "CeDeROM" CEDRO 2021-01-02 23:13:42 UTC
Whoops, %%OCTAVE_VERSION%% got replaced, but %%CONFIGURE_TARGET%% does not, thank you for the good catch Peter! :-)
Comment 2 Tomasz "CeDeROM" CEDRO 2021-01-03 01:12:58 UTC
Hmm on my 12.2-RELEASE-p1 platform I get stage like this:


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?
Comment 3 Tomasz "CeDeROM" CEDRO 2021-01-05 03:27:49 UTC
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:

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 :-)
Comment 4 Tomasz "CeDeROM" CEDRO 2021-01-05 03:29:52 UTC
Created attachment 221279 [details]
fixes octave paths and adds debug that is enabled by default.

Patch provided by Port Maintainer :-)
Comment 5 Tomasz "CeDeROM" CEDRO 2021-01-05 14:44:58 UTC
I just noticed that octave-config execution should be placed in conditional based on MOCTAVE selecton, will fix that asap, sorry :-)
Comment 6 Tomasz "CeDeROM" CEDRO 2021-01-05 14:56:48 UTC
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 ;-)
Comment 7 Tomasz "CeDeROM" CEDRO 2021-01-05 20:40:18 UTC
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? :-)
Comment 8 commit-hook freebsd_committer 2021-01-06 18:32:39 UTC
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

  fixes octave paths and adds debug that is enabled by default

  PR:		ports/252350
  Submitted by:	pcc <pcc@gmx.net>

Comment 9 Tomasz "CeDeROM" CEDRO 2021-01-06 18:51:16 UTC
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.
Comment 10 Tomasz "CeDeROM" CEDRO 2021-01-07 09:36:05 UTC
===>  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

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 :-)
Comment 11 Tomasz "CeDeROM" CEDRO 2021-01-08 06:26:04 UTC
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 :-)


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)
Comment 12 Tomasz "CeDeROM" CEDRO 2021-01-08 06:29:23 UTC
Created attachment 221376 [details]
port patch that fixed octave hardcode.

Port now takes octave paths from octave-config utility after dependency it installed.