Also, I guess when we publish 26.2, we'll need to remember to set appropriate headers for merge to the quarterly branch.

Thanks for working on it. Changes look good to me. I built the port with couple of permutations of various OPTIONs, and running it (12-amd64), and so far no problems. I've not tried building any dependent ports though.

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.