What's going to be the work directory of a port?

MG

MG

While trying out the port x11-fm/doublecmd and integrate it in a automated desktop compile system, how can I know the actual name of the work directory that will be used before the build starts? Doublecmd for some reason creates directory work-gtk2. A symlink work to it causes errors because files aren't found.
The Makefile has 3 lines that seem related but it's not clear to me what it means:
Code: 
gtk2_CONFLICTS_INSTALL= ${PORTNAME}-qt5 ${PORTNAME}-qt6
qt5_CONFLICTS_INSTALL=  ${PORTNAME}-gtk2 ${PORTNAME}-qt6
qt6_CONFLICTS_INSTALL=  ${PORTNAME}-gtk2 ${PORTNAME}-qt5
 
Code: 
$ make -C /usr/ports/x11-fm/doublecmd -V WRKDIR
/usr/ports/x11-fm/doublecmd/work-gtk2
$ make FLAVOR=qt5 -C /usr/ports/x11-fm/doublecmd -V WRKDIR
/usr/ports/x11-fm/doublecmd/work-qt5
$ make FLAVOR=qt6 -C /usr/ports/x11-fm/doublecmd -V WRKDIR
/usr/ports/x11-fm/doublecmd/work-qt6
 
Charlie_ said:
Code: 
$
[QUOTE="SirDice, post: 679429, member: 1677"]
Also,
[URL unfurl="true"]https://docs.freebsd.org/en/books/porters-handbook/makefiles/#makefile-wrkdir[/URL]
And
[URL unfurl="true"]https://docs.freebsd.org/en/books/porters-handbook/porting-dads/#porting-wrkdir[/URL]
[/QUOTE]
[/QUOTE
[/QUOTE]
The -gtk2 addition isn't mentioned in the Makefile. It's given somewhere else but I can't find it. It only has to be set to the default again: work. What even did change it?
Dependencies or possible conflicts are not relevant at this moment. We'll see that while running the program.
Click to expand...
 
This forum trips my Firefox to the level of unuseable. I give up commenting to that.
It has no clue of the input positioning in the forms.
 
MG said:
The -gtk2 addition isn't mentioned in the Makefile. It's given somewhere else but I can't find it. It only has to be set to the default again: work. What even did change it?
Click to expand...
The selected flavor is always appended, see here: https://cgit.freebsd.org/ports/tree/Mk/bsd.port.mk#n1709
In this special case, flavors are defined by a USES (lazarus:flavors) here: https://cgit.freebsd.org/ports/tree/Mk/Uses/lazarus.mk#n84

All in all, this is the default behavior of the ports framework, this port does not override the workdir.

I don't know what exactly you're trying to do (why would you ever need to access the workdir of a port in the first place), but then, make(1) makes it easy to query the fully expanded value of any variable as shown by Charlie_ – use that instead of "fighting" against how the ports work.
 
zirias@ said:
The selected flavor is always appended, see here: https://cgit.freebsd.org/ports/tree/Mk/bsd.port.mk#n1709
In this special case, flavors are defined by a USES (lazarus:flavors) here: https://cgit.freebsd.org/ports/tree/Mk/Uses/lazarus.mk#n84

All in all, this is the default behavior of the ports framework, this port does not override the workdir.

I don't know what exactly you're trying to do (why would you ever need to access the workdir of a port in the first place), but then, make(1) makes it easy to query the fully expanded value of any variable as shown by Charlie_ – use that instead of "fighting" against how the ports work.
Click to expand...
I'm tryng to fit it in a full system build script. It takes care of particular configuration settings, modifications and replacement or removal of unwanted parts for many other ports.
Ugly workaround is writing an independent install script only for this port but I'm not sure if I'll keep it part of the system. Need to see first if it has problems with samba not existing or something else. I like the configurability, though. It seems an interessting graphical mc replacement.
Another possible workaround is to assume the workdir is the first found directory that starts with 'work'.
Actual problem here is the portstree being unpredictable because it wants to know the context to do things dynamically.
 
MG said:
I'm tryng to fit it in a full system build script. It takes care of particular configuration settings, modifications and removal of unwanted parts for many other ports.
Click to expand...
My impulse would be that this should do whatever build configuration you think it should do and then use make package, so you can install with regular pkg(8). But anyways:
MG said:
Another possible workaround is to assume the workdir is the first found directory that starts with 'work'.
Click to expand...
... no, just query the correct value with make -V WRKDIR.
 
zirias@ said:
My impulse would be that this should do whatever build configuration you think it should do and then use make package, so you can install with regular pkg(8). But anyways:

... no, just query the correct value with make -V WRKDIR.
Click to expand...
Trying a clean run now. This wil take a few hours. I think I have been changing too much. It now complains about flag dot-files in the workdir while it doesn't exist.
The make -V command works. I have to add a new variable to a few scripts to make it universal.
 
build error. Same problem, now gdb:
Code: 
gmake[1]: Leaving directory '/usr/ports/devel/gdb/work-py39/.build/opcodes'
gmake[1]: Entering directory '/usr/ports/devel/gdb/work-py39/.build/gdb'
  CXXLD  gdb
  CXXLD  kgdb
ld: error: duplicate symbol: floatformat_to_double
>>> defined at floatformat.c
>>>            floatformat.o:(floatformat_to_double) in archive /usr/local/lib/libiberty.a
>>> defined at floatformat.c
>>>            floatformat.o:(.text+0x660) in archive ../libiberty/libiberty.a

Why must the workdir have a different name? Who wants several versions of ports within the same portstree?
 
You must log in or register to reply here.
Back
Top