Open jonassmedegaard opened 3 years ago
Argh - I see now that not only those header files gets installed, but also /usr/lib/x86_64-linux-gnu/libircd.so.3.0.2
and /usr/lib/x86_64-linux-gnu/libircd_matrix.so.0.0.1
and the usual set of symlinks for those.
Thanks, I think the ideal course here is to substitute some configurable $BRANDING that will end up prefixing includes, or some other namespace indeed. I've been considering ctor
.
Without endeavoring on any major changes at this time though, it might be possible to mitigate this issue by nesting the installed assets in a directory like /usr/include/ctor/
which would end up just containing /usr/include/ctor/ircd/
and the package would obviously adjust the -I/path
accordingly (since #include
expects <ircd/*>
.
As for linking, it's probably best to have libircd
as libircd_ctor
or somehow ctor/libircd
. That part might require some intervention, but probably a lot less than the top end.
correction: I was too quick about the concrete clash with package hybrid-dev
- that package is patched to instead use ircd-hybrid
as its namespace, specific for the Debian package.
The issue I raise remains that the default namespace clashes with the default namespace of other projects.
yes, sounds sensible to "push" the existing name into another new one. I am not skilled in programming that, though - so hope you would find it relevant to do the actual work :-)
Indeed this has been a wider issue with the many, many forks of IRCd over the decades :)
that package is patched to instead use ircd-hybrid as its namespace, specific for the Debian package.
Anything that can be done to make it ircd-ctor
in the same ways is desirable. Thank you!
Seems this works:
./configure --sysconfdir=/etc/construct --libdir=/usr/lib/ctor --includedir=/usr/include/ctor
I have only tried compiling (and not even completed that yet), not actually tried run the resulting code, so not certain if that needs messing with environment variable LD_LIBRARY_PATH
to locate the libraries at runtime.
Seems this works:
./configure --sysconfdir=/etc/construct --libdir=/usr/lib/ctor --includedir=/usr/include/ctor
I have only tried compiling (and not even completed that yet), not actually tried run the resulting code, so not certain if that needs messing with environment variable
LD_LIBRARY_PATH
to locate the libraries at runtime.
This looks very promising now, sweet! Don't mind posting up anything you've done even if some elements are broken/incomplete, or conflicts still exist. I surmised there might be some non-trivial effort required here eventually.
Not sure what more to provide here.
This is a full build log of a successful build by an official Debian autobuilder: https://buildd.debian.org/status/fetch.php?pkg=matrix-construct&arch=amd64&ver=0.6.103%7Edfsg1%2B%7E6.11.4-2&stamp=1619277253&raw=0
These are the relevant lines from that build log (including also the debhelper wrapper command, to indicate which options were not part of debhelper default configure flags:
dh_auto_configure -- --enable-generic --enable-opencl --sysconfdir=/etc/construct --libdir=/usr/lib/x86_64-linux-gnu/ctor --includedir=/usr/include/ctor --enable-optimize
./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --enable-generic --enable-opencl --sysconfdir=/etc/construct --libdir=/usr/lib/x86_64-linux-gnu/ctor --includedir=/usr/include/ctor --enable-optimize
Building and installing Construct introduces files below /usr/share/ircd which on Debian-based systems clash with files in package
hybrid-dev
.Other files clash as well, avoidable like this:
...but those header files seem unavoidable - other than not installing them at all.
If Construct really do share header files with the hybrid ircd server daemon, then I guess it would help if that was documented somewhere, so that in Debian we could break out the shared part as a separate package used by both sets of packages. Otherwise, it seems best if Construct would by default consistently use "construct" as its namespace, not "polute" namespaces from the projects it was (as I understand it) forked from.