• bsd.emacs.mk: update comments at top of file

The last TODO on my list is to check PORTREVISIONS to determine which should be bumped.

Side note, USE_EMACS -> USES=emacs ?

This looks good, editors/semi fails to package for some flavors though.

I think the dependencies should have ${EMACS_PKGNAMESUFFIX} and not ${PKGNAMESUFFIX}, a bit like the Python ports do, it makes it more clear what is really happening.

A goal with the flavor names was to introduce consistency with other ports (e.g., like vim, have a -lite variant). But, the vim-lite package was just renamed to vim-console, so I am open to suggestions. Should we stick with -nox11, -lite, match vim and use -console, or use something different?

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 ?

2. And if I specify FLAVOR=devel on command-line, or in make.conf(5) (to avoid passing flavor explicitly everytime), does that mean I am specifying that I would like to have devel FLAVOR for all ports in the build scope (wherever it's implemented), or devel FLAVOR name will now get reserved for Emacs ports.

3. Also do you have some UPDATING note prepared for users to inform about such changes, as that will help me get answer to the some of the questions. If not then maybe time to work on it ?

Thanks!

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 ?

You will get the default flavor, so probably foobar-emacs25. If you need another one, you run make -C foobar install FLAVOR=xxx.

2. And if I specify FLAVOR=devel on command-line, or in make.conf(5) (to avoid passing flavor explicitly everytime), does that mean I am specifying that I would like to have devel FLAVOR for all ports in the build scope (wherever it's implemented), or devel FLAVOR name will now get reserved for Emacs ports.

Setting FLAVOR=devel in your make.conf will break every port that do not have a devel flavor. (And build this flavor for ports that do.)

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 ?

Thanks for confirmation, that's what I was expecting.

You will get the default flavor, so probably foobar-emacs25. If you need another one, you run make -C foobar install FLAVOR=xxx.

2. And if I specify FLAVOR=devel on command-line, or in make.conf(5) (to avoid passing flavor explicitly everytime), does that mean I am specifying that I would like to have devel FLAVOR for all ports in the build scope (wherever it's implemented), or devel FLAVOR name will now get reserved for Emacs ports.

Setting FLAVOR=devel in your make.conf will break every port that do not have a devel flavor. (And build this flavor for ports that do.)

So, this seems inconvenient for one to remember specifying FLAVOR everytime they install an emacs dependent port when they deviate from defaults, and as I proposed in my other comment, I think we can handle this better by letting user specify their preference through make.conf(5).

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

In D13506#292150, @mat wrote:

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

There may be confusion, because the Emacs flavors describe more than the version. Maybe something like DEFAULT_FLAVORS+=... or DEFAULT_EMACS_FLAVOR?

@ Nobody says that the emacs version must only be , it can be whatever you want, including a combination of versions and flavor, look at what mysql has.
Please, do not invent a new variable for setting some defaults when there is something already here.

In D13506#292150, @mat wrote:

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

Yes, seems to me too, as if we encounter some emacs dependent port which has both python ports as dependencies, then specifying FLAVOR will break either Python, or Emacs dependency.

For me, I think we should restrict flavours only to various editors/emacs* ports, and not to dependencies. And dependencies can instead refer to the Emacs flavour user has opted for in DEFAULT_VERSIONS.

I think that a flavor that is set on the command line should take precedence over whatever is set for a default flavor in make.conf. But, how can we determine if the FLAVOR has been set on the command line and not because it was the default flavor, ${FLAVORS:[1]}? There is .MAKEOVERRIDES:=${.MAKEOVERRIDES:NFLAVOR} so .MAKEOVERRIDES is not an option. Then, again, there is the annoyance that the default flavor will not be supported by all Emacs ports. Is this convenience of allowing the default flavor in make.conf a showstopper now? Could it be added later? I am not aware of any other flavorized ports that support this. Also, my estimate of the overlap in the Venn diagram of users that 1) want to build the port (outside of poudriere), 2) do not want the default flavor, 3) cannot specify FLAVOR=blah on the command line is 3 users. :-P

I also brought this up in IRC and this was @bapt's response,

<bapt> this is exactly to avoir DEFAULT_VERSIONS that flavors do exists
<bapt> the best imho would be to introduce a new thing for make.conf
<bapt> like we do for otions
<bapt> instead of playing badly with DEFAULT_VERSIONS :)

So, maybe we could eventually add DEFAULT_FLAVORS=emacs=lite,vim=console,....

I broke down and added a way to specify the default Emacs flavor in make.conf using DEFAULT_VERSIONS. Tests are now running to build all ports with all flavors. I will report back and if all is well and everyone is happy, I will add an entry to UPDATING.

In D13506#292428, @jrm wrote:

I think that a flavor that is set on the command line should take precedence over whatever is set for a default flavor in make.conf. But, how can we determine if the FLAVOR has been set on the command line and not because it was the default flavor, ${FLAVORS:[1]}? There is .MAKEOVERRIDES:=${.MAKEOVERRIDES:NFLAVOR} so .MAKEOVERRIDES is not an option. Then, again, there is the annoyance that the default flavor will not be supported by all Emacs ports. Is this convenience of allowing the default flavor in make.conf a showstopper now? Could it be added later? I am not aware of any other flavorized ports that support this. Also, my estimate of the overlap in the Venn diagram of users that 1) want to build the port (outside of poudriere), 2) do not want the default flavor, 3) cannot specify FLAVOR=blah on the command line is 3 users. :-P

The flavor used to build a port does not propagate to dependencies, it is by design, because not all dependencies may need it, and they may need different flavors. If the dependencies need a flavor, you have to make sure the flavor is added to the dependency line.

I also brought this up in IRC and this was @bapt's response,

<bapt> this is exactly to avoir DEFAULT_VERSIONS that flavors do exists
<bapt> the best imho would be to introduce a new thing for make.conf
<bapt> like we do for otions
<bapt> instead of playing badly with DEFAULT_VERSIONS :)

So, maybe we could eventually add DEFAULT_FLAVORS=emacs=lite,vim=console,....

Maybe, yes. Though it may work for emacs, it would not work for Python because of the Python 2 vs Python 3 chasm, as if you say DEFAULT_FLAVORS+= python=py27 and the port USES=python:3.4+ then what is the default Python flavor ? Is the port ignored ? Do we say it's py36 ? Right now, it uses PYTHON_DEFAULT, then PYTHON2_DEFAULT, then PYTHON3_DEFAULT.

I think/hope we are all set. If so, I believe portmgr approval is required.

Yes, time has come when you can open a PR and ask for an exp-run.

In D13506#294362, @mat wrote:

Yes, time has come when you can open a PR and ask for an exp-run.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225404

The exp-run exposed one issue that has been fixed. Could we get portmgr approval to commit this?

Can you update the review with what will be committed ?

The .include "${PORTSDIR}/Mk/bsd.emacs.mk" has to be removed from Mk/bsd.port.mk too.

I see two issues after committing.

1. I foolishly misinterpreted https://lists.freebsd.org/pipermail/freebsd-git/2015-April/000038.html to also apply to the move of japanese/migemo-emacs23 to japanese/migemo-emacs. The svn history was preserved for the files, but not the directory.
2. For some reason the svn history was not preserved with the move of Mk/bsd.emacs.mk to Mk/Uses/emacs.mk. I definitely did do: git mv Mk/bsd.emacs.mk Mk/Uses/emacs.mk.

These git svn dcommit shortcomings are unfortunate. It's quite convenient to commit this way, but if it screws up the svn history, I will avoid it in the future except for simpler situations.

Now, I supposed I will have to back out these changes, patch an svn repository and commit directly with svn commit.

In D13506#297072, @jrm wrote:

I see two issues after committing.

1. I foolishly misinterpreted https://lists.freebsd.org/pipermail/freebsd-git/2015-April/000038.html to also apply to the move of japanese/migemo-emacs23 to japanese/migemo-emacs. The svn history was preserved for the files, but not the directory.
2. For some reason the svn history was not preserved with the move of Mk/bsd.emacs.mk to Mk/Uses/emacs.mk. I definitely did do: git mv Mk/bsd.emacs.mk Mk/Uses/emacs.mk.

These git svn dcommit shortcomings are unfortunate. It's quite convenient to commit this way, but if it screws up the svn history, I will avoid it in the future except for simpler situations.

Now, I supposed I will have to back out these changes, patch an svn repository and commit directly with svn commit.

Git does not track file moves at all, also, it does not track directories. This is why in many projects, you have empty files named .gitkeep in empty directories, so that the directory are kept.

Whenever I have a patch in my git repository that has files moves or copies, I always fallback to subversion for the commit itself. I agree that this is a pain.

Does this look right? This is my first revert and it seems like a tricky one.

svn copy svn+ssh://repo.freebsd.org/ports/head/japanese/migemo-emacs23@460620 japanese
svn rm japanese/migemo-emacs
svn mv japanese/migemo-emacs23 japanese/migemo-emacs
copy files under japanese/migemo-emacs from Phab revision

svn copy svn+ssh://repo.freebsd.org/ports/head/Mk/bsd.emacs.mk@460620 Mk/
svn rm Mk/Uses/emacs.mk
svn mv Mk/bsd.emacs.mk Mk/Uses/emacs.mk
copy emacs.mk from Phab revision

commit

In D13506#297104, @jrm wrote:

Does this look right? This is my first revert and it seems like a tricky one.

svn copy svn+ssh://repo.freebsd.org/ports/head/japanese/migemo-emacs23@460620 japanese
svn rm japanese/migemo-emacs
svn mv japanese/migemo-emacs23 japanese/migemo-emacs
copy files under japanese/migemo-emacs from Phab revision

svn copy svn+ssh://repo.freebsd.org/ports/head/Mk/bsd.emacs.mk@460620 Mk/
svn rm Mk/Uses/emacs.mk
svn mv Mk/bsd.emacs.mk Mk/Uses/emacs.mk
copy emacs.mk from Phab revision

commit

It looks ok, but it will not work because you cannot replace files in one commit, you have to do it in two steps.

# save japanese/migemo-emacs and Mk/Uses/emacs.mk
svn rm japanese/migemo-emacs Mk/Uses/emacs.mk
svn commit

svn copy svn+ssh://repo.freebsd.org/ports/head/japanese/migemo-emacs23@460620 japanese/migemo-emacs
svn copy svn+ssh://repo.freebsd.org/ports/head/Mk/bsd.emacs.mk@460620 Mk/Uses/emacs.mk
# Copy the saved files at step 1
svn commit