Re: gcc won't build i386 with our cctools assembler hack

2020-03-03 Thread Ken Cunningham
So, second notice / heads up on this.

Plan is:

to roll back to libgcc / gcc 7.4.x on 10.4, 10.5, and maybe on i386 10.6.

to conflicts_build every clang version >= 5.0 when build_arch is i386 on every 
gcc version >= 5.

and then this will perhaps stay like this forever, or at least until some 
solution comes along to the libgcc / i386 building issues.

I assume anyone who cares already knows all the details, but feel free to ask 
if you have any questions or have the insight to come up with any solutions.

Bet,

Ken



python portgroup best practices for apps (and how to migrate a port from module to app)

2020-03-03 Thread Enrico Maria Crisostomo
Hi all,

Yesterday a brief discussion started in macports-ports PR #6496
 where we were
arguing about python apps best practices. Basically, a port update
submission was made to add variants to a port (httpie) to support
additional python versions. The PR author notices:

There are ports like httpie which tracks latest python version, others like
> pgcli which use variants and finally ports like py-awscli which use
> subports. None of them are usable as libraries.


I had this very doubt a few days ago, when I updated the docker-compose
port. The python portgroup sources (python-1.0.tcl) state:

# Usage:
# name should be of the form py-foo for modules
# subports pyXY-foo are declared for each XY in python.versions

# for apps (i.e. not named py-foo), no subports will be defined
# only the python.default_version will be used
# you can change that in variants if you want

I'm inclined to say, then, that the PR author approach is correct, in which
case I would also be compelled to migrate other ports I maintain (as the
aforementioned py-awscli). Also, this would have the side effect of
gracefully transition users to the latest python version supported by a
port.

What's your opinion about this?

Also, should I migrate py-awscli to awscli, what would the recommended
course of action be to guarantee that the experience of current users of
py-awscli wouldn't be negatively affected?

Thanks,
Enrico