conda-forge / conda-forge/conda-forge.github.io

What is our limit in terms of low level packaging

Đang mở
#81 7 bình luận 0 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
JavaScript
Star
170
Fork
320
Merge trung bình
2 ngày 10 giờ
Pull request đã merge (30 ngày)
5

Mô tả

I have opted to break this out as an issue as this is a real world problem that deserves careful consideration before proceeding. In particular, sometimes we need newer versions of system tools. This was inspired by this issue ( https://github.com/conda-forge/staged-recipes/pull/300 ).

One point is do we package assemblers. This is interesting as we currently do package `yasm` We need `yasm` to build other dependencies (`x264`, `ffmpeg`, possibly other things in the future). Also, in the case of `yasm`, it is packaged as cross platform (all platforms, even Windows) so I don't know that there is a way around it. We may need to add `nasm` in the future too.

There are also some cases we have found it better to package our own build tools like `m4`, `bison`, `flex`, `libtool`, `automake`, `autoconf`, `pkg-config`, etc. There are many reasons for this that range from the system versions being too old (often the case with Mac, sometimes Linux too), having more consistency across platforms, having more control of the build process, etc. The line between too low and acceptable to package is still pretty fuzzy in this case. For example, should `ar` be packaged? It isn't that complicated and it could be useful to have a newer version in some cases. Similar arguments could be added for other binutils too.

One thought might be we don't package tools that are OS specific. However, I don't expect that to hold as I think we definitely need to package `patchelf` and we will want that in conda-forge so that we can ensure we have the latest version (as it still hasn't hit 1.0, but it is getting close). There also has been discussion of having a newer version of `clang` for Mac, which would presumably require packaging. Though that point is far from settled.

Another thought might be we don't want to package standard system development tools. However, this point could be sort of contentious as we use `gcc` from a package at present. I expect this will be a topic of a fair amount of debate especially as we engage other conda-recipe communities that have opted for different build strategies.

Please feel free to share your thoughts on this point.

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.