Opened 10 years ago

Closed 9 years ago

#29145 closed enhancement (fixed)

llvm: don't use a versioned docdir

Reported by: ryandesign (Ryan 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)

patch-llvm-docdir.diff (617 bytes) - added by ryandesign (Ryan Schmidt) 10 years ago.
proposed patch

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by ryandesign (Ryan Schmidt)

Attachment: patch-llvm-docdir.diff added

proposed patch

comment:1 Changed 10 years ago by ryandesign (Ryan Schmidt)

Keywords: haspatch added

comment:2 Changed 10 years ago by mfeiri

Cc: erickt@… added; mfeiri@… removed
Owner: changed from erickt@… to mfeiri@…
Status: newassigned

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 10 years ago by ryandesign (Ryan 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 9 years ago by jmroot (Joshua Root)

Cc: jeremyhu@… added

I guess this is fixed/wontfix now?

comment:5 Changed 9 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.