 |
 |
> I assume that the user _doesn't_ need `xrootd` to be installed, because the client library should contain everything they need to talk with a remote server? Correct, as it is done as part of the CI in a `gitlab-registry.cern.ch/linuxsupport/cc7-base:latest` container: https://github.com/xrootd/xrootd/blob/cdb6b2223d153910af558cd8650ebaf7fec432cc/.github/workflows/build.yml#L635-L644 So I guess we need to understand what isn't being set right in Debian based systems. I also didn't do a good enough job showing last night (sorry, probably better to just _not_ post at all late at night) that the Dockerfile I shared was to demonstrate that the libraries being found is the core problem that is being faced. > OK, I took a deeper look at this, and I've realised that the build chain is a lot more complicated than I expected. The sdist on PyPI is a "pseudo package" that has [its own `setup.py`](https://github.com/xrootd/xrootd/blob/cdb6b2223d153910af558cd8650ebaf7fec432cc/packaging/wheel/setup.py), which launches a [separate build step](https://github.com/xrootd/xrootd/blob/cdb6b2223d153910af558cd8650ebaf7fec432cc/packaging/wheel/install.sh) for [the bindings](https://github.com/xrootd/xrootd/blob/cdb6b2223d153910af558cd8650ebaf7fec432cc/bindings/python/setup.py.in). Yeah, while I don't think I will be the person to spend time revising the build system, it would be great to see a more modern approach (e.g. `pybind11` / `scikit-build`) here in general. A GitHub Issue for it would probably be good to have, even to mark it for posterity. -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1668#issuecomment-1088821326 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1