Allow building with unvendored dependencies

[FFY00]

prjxray vendors 3rd party dependencies, such as yosys, this is not optimal for distro packages. Would it be possible to add an option to build without vendoring the dependencies?

[litghost]

Can you be more concrete? Neither setup.py nor requirements depend on yosys.

[FFY00]

Ah, sorry! yosys is only used for the tests.

Other dependencies are vendored though:
https://github.com/SymbiFlow/prjxray/blob/master/CMakeLists.txt

GitHub

SymbiFlow/prjxray

Documenting the Xilinx 7-series bit-stream format. - SymbiFlow/prjxray

[FFY00]

Or are they also only used for the tests?

[litghost]

I'm not familiar with your use of the word "vendored" in this context. What do you mean?

[FFY00]

It means that you provide your own dependencies, instead of using external distributions. You build them from source and static link them to the library. I am asking for an option to instead dynamic link against the shared libraries provided by my Linux distribution.

https://github.com/SymbiFlow/prjxray/blob/b243db2d05f6a3c76f0405737702a8b7e375701f/lib/CMakeLists.txt#L29

[litghost]

It means that you provide your own dependencies, instead of using external distributions. You build them from source and static link them to the library. I am asking for an option to instead dynamic link against the shared libraries provided by my Linux distribution.

What is the goal of adding dynamic linking in this case? The current build products I believe have no dynamic dependencies other than the standard ones (libc, libm, etc).

[FFY00]

What is the goal of adding dynamic linking in this case?

I am packaging prjxray for Arch Linux, I should link against the system libraries. Imagine I have 15 packages in the repos that depend on yaml-cpp, if they static link, I have 15 duplicated copies of yaml-cpp. Apart wasting more space and bandwidth, it is also a mess to keep track of security vulnerabilities for eg. If yaml-cpp gets a CVE, I need to find out which packages vendor it and patch the CVE everywhere. These are just some examples from the top of my mind. Static linking is just not how Linux distributions do things.

The current build products I believe have no dynamic dependencies other than the standard ones (libc, libm, etc).

Yes, because it static links the dependencies 😄.

[mithro]

@FFY00 - There is some work to extract the C++ tools in this repository into its own repository. After that is done things will be in a better position to support dynamic linking.