*-devel ports for llvm and gcc

Ryan Schmidt ryandesign at macports.org
Fri May 13 01:27:54 PDT 2016


> On May 12, 2016, at 3:51 AM, René J. V. Bertin <rjvbertin at gmail.com> wrote:
> 
> Ryan Schmidt wrote:
> 
> 
>>> is released as a stable version it should be renamed to llvm-3.9. The
>>> ports llvm-3.9 and llvm-3.9-devel are still drop-in replacements.
>> 
>> This makes it much more difficult on developers when the time comes for a port
>> to graduate from development to stable status, as I'm currently doing with
>> gcc6. I don't want to impose that extra work on myself or other developers.
> 
> Why? As you said yourself all that's needed is using a path:-style dependency. 
> That's hardly extra work,

It is extra work for the maintainer to convert all the existing port: dependencies to path: dependencies. It is extra work for the maintainer to rename the port from -devel to non-devel when it goes stable, and to maintain for one year the -devel stub port marked as replaced_by the non-devel port to facilitates upgrades. It is extra work for the user to manually uninstall the -devel port after the port has been renamed to the non-devel version, since MacPorts currently does not do so automatically (https://trac.macports.org/ticket/27552). And all this extra work for no benefit.


> and it's probably a good idea to leave that style in 
> place even after the release version of the dependency is produced. It's 
> probably not because llvm 3.8.1 goes stable that there will be no 3.8.1+i that 
> could be tested as a -devel port first.

I don't have any interest in continuing to offer development versions of a port that has gone stable, in the case where we offer multiple versions of that port.


> The advantage of using a -devel (sub)port rather than (or in addition to) a 
> category is that other ports can actually depend on the -devel port, if 
> necessary. For instance, clang-3.8-devel (clang-devel-3.8?) would probably have 
> to depend on llvm-3.8-devel (llvm-devel-3.8).

No need for this, if there are no -devel ports for these, as there currently aren't.


> Also, -devel subports can in many cases be subports of the main/release port 
> because they most likely share a lot of code. I do that all the time with my KF5 
> ports.



More information about the macports-dev mailing list