prjxray icon indicating copy to clipboard operation
prjxray copied to clipboard

Allow building with unvendored dependencies

Open FFY00 opened this issue 5 years ago • 8 comments

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?

FFY00 avatar Jun 26 '20 23:06 FFY00

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

litghost avatar Jun 26 '20 23:06 litghost

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

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

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

FFY00 avatar Jun 26 '20 23:06 FFY00

Or are they also only used for the tests?

FFY00 avatar Jun 26 '20 23:06 FFY00

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

litghost avatar Jun 26 '20 23:06 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.

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

FFY00 avatar Jun 26 '20 23:06 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.

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

litghost avatar Jun 26 '20 23:06 litghost

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

FFY00 avatar Jun 26 '20 23:06 FFY00

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

mithro avatar Jun 28 '20 00:06 mithro