matrix-construct / construct

This is The Construct
Other
366 stars 43 forks source link

non-unique header files /usr/include/ircd/* #179

Open jonassmedegaard opened 3 years ago

jonassmedegaard commented 3 years ago

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:

STEM = construct
CONFIGURE_ARGS += --sysconfdir=/etc/$(STEM) --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)/$(STEM)/

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

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

jevolk commented 3 years ago

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.

jonassmedegaard commented 3 years ago

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.

jonassmedegaard commented 3 years ago

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 :-)

jevolk commented 3 years ago

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!

jonassmedegaard commented 3 years ago

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.

jevolk commented 3 years ago

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.

jonassmedegaard commented 3 years ago

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