Re: compiler_wrapper portgroup
On May 7, 2021, at 12:13, Chris Jones wrote: > Hi, > > It solves a number of problems, but mostly it boils down to not all build > systems or projects supporting the standard rules we use in macports for > passing flags erc. to the underlying compilers. Legacy support PG for > instance requires this to function and a number of ports, or a bunch of ports > using a given build system, did not work with it. E.g. Certainly the legacy support portgroup didn't used to require compiler wrappers... > 1 The go based ports. I experimented for a long time trying to get them to > work with legacy-support in the ‘standard’ way but in the end it just was not > compatible with how this build system works. So I added a wrapper there, > locally at first in the PG and with that all the go ports now build down to I > think 10.7, whereas before it was limited to I think 10.12 and newer. > > 2. Rust. Same deal as go. Now works down to 10.9. > > 3. Bazel. This build system really goes out of its way to not allow you to > modify its build environment. Again, wrapping the compilers in scripts which > you then tell the build system to use is a great way to circumvent this. > > 4. Finally, macports has support for ccache integrated, but it is a little > hit and miss as to where it works. It didn’t work with bazel, but with the > wrapper now will does. Similarly for all the python group ports, they also > use the wrapper and as such work with ccache. If you have ever tried to work > on ports like py-tensorflow or py-pytorch having ccache now working is a huge > boost. Same for the makefile PG, it also now works with ccache. > > So.. after implementing compiler wrappers in a number of places I decided it > made sense to centralise it in one place. Certainly MacPorts base could have used compiler wrappers from the beginning, either to add its flags or to implement its ccache and distcc support. I'm assuming there were reasons why it didn't, other than just nobody got around to doing it. I've thought about it before too, but there are problems with the approach. For example, your compiler wrappers use ccache if requested and include the legacy support flags if needed, but this means that when we look at a port's main.log or debug output, we won't see the word ccache or the legacy support flags so we won't know if they're present in the compiler wrapper or not; this could hinder debugging. (This is why we want ports to build with silent rules disabled: so that we can see the exact compiler invocations with all the args and environment variables.) Another problem is that some build systems inspect the compiler path. It's probably a bad idea for a build system to do that and it should be fixed, but if there are any build systems out there that check for example if the compiler path is exactly "/usr/bin/clang" and do something in response to that, then that would fail if the compiler path is your compiler wrapper.
Re: python port notes suggest to "select" one -- but do we want that
On May 8, 2021, at 13:40, Ken Cunningham wrote: > Sat am ponder: > > I just updated python and saw the note displayed to select a python if you > want it the default. > > However we/I spend lots of time undoing this kind of thing, asking people to > unselect everything, when their builds inevitably fail. > > Perhaps this note might be considered not so helpful then, as we actually > don’t want people (for the most part) to select anything. > > And now back to your regularly scheduled programming… The wording of the message (of every port that can be selected, not just python) could be improved. It currently starts with "To make this the default Python", perhaps implying that the user *should* do this or that the installation is incomplete without doing this. It might be better if it started with "If you would like to make this the default Python", hopefully better conveying the truth that the user *can* do this but does not need to. MacPorts offers and supports the select mechanism. If any ports fail to build when something has been selected, that is a bug in the port that should be fixed.
Re: Ports updated without maintainer notification?
In this particular situation, the libraries in question are ones that I specifically added to MacPorts in order to allow my Blender port to build. No other ports use those libraries, although obviously there's nothing to prevent other software from starting to use them in the future. -- Jason Liu On Tue, May 11, 2021 at 7:08 PM Nils Breunese wrote: > Ryan Schmidt wrote: > > > Holding back a library to be compatible with one port may not be the > right choice for other ports that depends on the library. > > If other ports would want to use the latest version of foo-lib, but > Blender needs specifically version 1.15 of foo-lib, it might be an idea to > have both a foo-lib port with the latest version and a foo-lib-1.15 port > that Blender can then depend on. > > Nils.
Re: Ports updated without maintainer notification?
Ryan Schmidt wrote: > Holding back a library to be compatible with one port may not be the right > choice for other ports that depends on the library. If other ports would want to use the latest version of foo-lib, but Blender needs specifically version 1.15 of foo-lib, it might be an idea to have both a foo-lib port with the latest version and a foo-lib-1.15 port that Blender can then depend on. Nils.
Re:APSL in macports
Thanks, I’ll try to port it. APSL2. Johan Verzonden via Yahoo Mail voor iPhone Op dinsdag, mei 11, 2021, 4:35 PM schreef Joshua Root : On 2021-5-12 00:31 , Johan Ceuppens via macports-dev wrote: > Hello, > > Is there a place for Apple Sourced code in the source tree ? So APSL 1 > or 2 licensed ? > > I would like to donate an RPG but since it has been sold to Apple, I > cannot GPL or BSD license it. It has to be refactored and coded still. > > Best regards, > Johan Ports of APSL-licensed projects are certainly fine. If you have a choice of which version to release under, APSL-2 is greatly preferable. - Josh
Re: APSL in macports
On 2021-5-12 00:31 , Johan Ceuppens via macports-dev wrote: Hello, Is there a place for Apple Sourced code in the source tree ? So APSL 1 or 2 licensed ? I would like to donate an RPG but since it has been sold to Apple, I cannot GPL or BSD license it. It has to be refactored and coded still. Best regards, Johan Ports of APSL-licensed projects are certainly fine. If you have a choice of which version to release under, APSL-2 is greatly preferable. - Josh
APSL in macports
Hello, Is there a place for Apple Sourced code in the source tree ? So APSL 1 or 2 licensed ? I would like to donate an RPG but since it has been sold to Apple, I cannot GPL or BSD license it. It has to be refactored and coded still. Best regards,Johan Verzonden via Yahoo Mail voor iPhone
