Opened 14 years ago
Closed 13 years ago
#29145 closed enhancement (fixed)
llvm: don't use a versioned docdir
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | mfeiri |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.9.2 |
Keywords: | haspatch | Cc: | erickt@…, jeremyhu (Jeremy Huddleston Sequoia) |
Port: | llvm |
Description
llvm has a patchfile to make it install documentation in /opt/local/share/doc/llvm-2.9 but we would rather not have the version number in that directory name. The attached patch fixes this. The portfile revision would also have to be increased, but I'd like to commit this patch at the same time as #29069 so users only have to rebuild once.
Attachments (1)
Change History (6)
Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Attachment: | patch-llvm-docdir.diff added |
---|
comment:1 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | haspatch added |
---|
comment:2 Changed 14 years ago by mfeiri
Cc: | erickt@… added; mfeiri@… removed |
---|---|
Owner: | changed from erickt@… to mfeiri@… |
Status: | new → assigned |
I think this patchfile is included for historic reasons only and under normal circumstances I'd support every effort to reduce deviations from upstream. But in this case I think we need to think about _fully_ versioned ports of llvm. The llvm-gcc42 compiler just reached its end-of-life and will continue to depend on llvm version 2.9 while our llvm port will move on to newer versions. I currently see three options:
a) llvm29, llvm30, llvm31, .... where each port conflicts the other ports. This will frequently require manual conflict resolution during upgrades of dependent ports (e.g. clang).
b) llvm29, llvm30, llvm31, .... where each port installs headers in versioned subdirectories and renames executables with versioned suffixes. Notify users about this and patch dependent ports to use these specific directories/executables. Maybe introduce something like a llvm_select tool.
c) Continue the llvm port as is but do not support llvm as a build dependency. Notify users about this and change all dependent ports to build their own compatible version of llvm and link statically
None of these options seems particularly attractive. Suggestions?
comment:3 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
In this case, I'm not advocating reducing deviations from upstream (though generally that's a great idea); I'm advocating conformance with MacPorts best practices. Several years ago, Anthony Ramine (nox) decided we should use ${name}-${version} as our docdir name, and we tried that for awhile (for example, during the time that #15724 was filed and resolved), but we later decided there was no purpose for including the version in the docdir if there's only a single port, and thus only a single version active at any given time. That's what my patch in this ticket addresses. But if you're considering having multiple llvm version ports, then that might change things.
Of the above options you've presented, a) is not ok; the llvm29 llvm30 llvm31 port naming scheme implies in MacPorts that all of these can be installed simultaneously and they do not conflict. c) Seems needlessly complex. I'd say that leaves b) as the correct solution. Note that any hypothetical llvm_select tool would be for the user's convenience, but could not be used or relied upon by portfiles that need llvm.
We can also simply b) a bit, and just create an llvm29 port for the benefit of the llvm-gcc42 port, and keep the llvm port continuing on to whatever the current version of llvm is. That would probably be the best plan. This matches how we've handled automake (automake17), autoconf (autoconf213 autoconf263), apr-util (apr-util0), etc.
comment:4 Changed 13 years ago by jmroot (Joshua Root)
Cc: | jeremyhu@… added |
---|
I guess this is fixed/wontfix now?
comment:5 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
llvm-2.9, llvm-3.0, presumably llvm-3.1 install documentation into ${prefix}/share/doc/${name} as desired, so I'll call it fixed.
proposed patch