Alright, looks good to me too. I don't see emacs linking to liblockfile being linked to, if it's installed, and MAILUTILS is off, and everything else is fine too.

Thanks for working on this. Your changes look good in theory. I'm running a test build, and it'll take me few hours (courtesy: webkit2-gtk3 ) to confirm they're good indeed.

Just realized that since this update involves a new Emacs release, are you also planning to update Mk/Uses/emacs.mk and PORTREVISION bump all emacs-dependent ports ?

Thanks, looks good to me.

In D15472#327069, @meta wrote:

Add NO_ARCH=yes

Changes look good. Also, could you please also add NO_ARCH=yes as it's architecture neutral port ?

Sorry for the delay in follow-up. Looks good to me.

Hi Joseph,

Looks good now.

Looks good to me. Can be committed.

In D13506#292150, @mat wrote:

Adding a DEFAULT_VERSIONS+=emacs=xxx seems like the best idea.

In D13506#291664, @mat wrote:

In D13506#291612, @ashish wrote:

I'm not super familiar with ports flavors, and learning as I review stuff, I'll post questions:

1. In pre-flavors (or before D13506 gets committed) era, if I use/install emacs-devel port (non-default emacs port) on my computer, and would like to use a port foobar which provides .el files and therefore specifies dependency on emacs port. Which emacs port it needs to depend on was decided by EMACS_PORT_NAME variable which is to be defined by user in make.conf(5), in case they're using non-default emacs port (like emacs-nox11, or emacs-devel as in my case). What is the solution for this situation in post-flavors era ? If I am not a packages user, and I do, make -C foobar install, what will I get, foobar-emacs25, foobar-emacs27, or what ?

I'm not super familiar with ports flavors, and learning as I review stuff, I'll post questions:

In D11558#240893, @tcberner wrote:

Is there any reason not to always build with profiling and dynamic ? If not I would also like to get rid of these options. Because, it just makes stuff unnecessary breaky and buggy, as the last comment shows.

devel/hs-transformers-base is failing with following:

Thanks for this. I used to do this by compiling the list of dependent ports from INDEX file, which is broader than these list of changes, and was theoretically good. Although, your approach is better, and seems more precise. Please go ahead.

Works fine for me too. Please go ahead and commit.

This one also looks good. Please proceed.

Looks good to me, and seems to build fine. Please proceed with commit.

Looks good to me. Please proceed.

Looks good to me. Please proceed.

In D9287#192339, @jrm wrote:

implicit approval for updates that only include a PORTREVISION bump? For the development version, I feel it's important to have frequent updates, so new bugs in the master branch are discovered as early as possible.

The diff looks good, although xwidgets option is broken, because it relies on a later version of WebKit GTK3 which is not yet in ports tree, so might want to add a IGNORE clause for that, or just remove it for now.