Page MenuHomeFreeBSD

Emacs flavors and cleanup
ClosedPublic

Authored by jrm on Dec 16 2017, 1:57 AM.

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
jrm added a comment.Dec 31 2017, 2:15 PM
  • bsd.emacs.mk: update comments at top of file
jrm added a comment.Dec 31 2017, 2:17 PM

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

jrm retitled this revision from A first attempt to create flavors for editors/emacs, editors/emacs-devel, and ports with USE_EMACS. to Emacs flavors and cleanup.Dec 31 2017, 2:19 PM
jrm edited the summary of this revision. (Show Details)
jrm edited the test plan for this revision. (Show Details)
jrm updated this revision to Diff 37319.Dec 31 2017, 6:15 PM
  • Update PORTREVISION and clean up flavorized Emacs ports
jrm updated this revision to Diff 37335.Jan 1 2018, 12:03 AM
  • math/proofgeneral: Fix pkg-plist issue
jrm updated this revision to Diff 37339.Jan 1 2018, 1:13 AM
  • fix issue with last diff
mat added a comment.Jan 2 2018, 2:51 PM

Side note, USE_EMACS -> USES=emacs ?

cad/dinotrace/Makefile
5 ↗(On Diff #37339)

This is most likely wrong.
It would go backwards.
Never forcefully change PORTVERSION to DISTVERSION if the version does not change.

cad/verilog-mode.el/Makefile
5 ↗(On Diff #37339)

Never change PORTVERSION to DISTVERSION if the version does not change. (This goes for the remaining of the patch.)

jrm updated this revision to Diff 37411.Jan 2 2018, 3:32 PM
  • Revert forced PORTVERSION -> DISTVERSION change

    cad/dinotrace is good example of why this is stupid.
mat added a comment.Jan 4 2018, 4:14 PM

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

jrm updated this revision to Diff 37560.Jan 5 2018, 4:41 PM
  • editors/semi: Fix a pkg-plist issue
jrm updated this revision to Diff 37576.Jan 6 2018, 2:31 AM
  • A first attempt at converting USE_EMACS to USES=emacs
jrm updated this revision to Diff 37577.Jan 6 2018, 2:34 AM
  • A first attempt at converting USE_EMACS to USES=emacs
jrm updated this revision to Diff 37578.Jan 6 2018, 3:06 AM
  • Rename japanese/migemo-emacs23 so that it does not include version
jrm updated this revision to Diff 37592.Jan 6 2018, 5:45 PM
  • audio/emms, databases/bbdb: Fix build on 10
  • Both ports fail with base texinfo, so depend on print/texinfo.
  • Silence portlint warnings.
  • Update and simplify audio/emms.
mat added a comment.Jan 8 2018, 4:21 PM

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.

jrm updated this revision to Diff 37636.Jan 8 2018, 5:54 PM
  • Use ${EMACS_PKGNAMESUFFIX} for dependencies
jrm added a comment.Jan 11 2018, 9:04 PM

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?

ashish requested changes to this revision.Jan 15 2018, 11:18 AM
ashish added inline comments.
editors/emacs/Makefile
48 ↗(On Diff #37636)

@jrm --- sorry for the late feedback. How about we keep CANNA option, and instead make the canna flavour turn ON that option, that way port will be backward compatible, and for users who are already running emacs with that option, can just continue to build/install emacs that they are already running without changes, in other words, this will be the least distractive path for them ? In other words, lets re-add CANNA option stuff (in Makefile, and pkg-plist), so if user does make config it will continue to see CANNA option. The only nitpicking with this approach is pkg-descr will continue to have CANNA support attribution line, even though user is not running CANNA enabled version, which IMHO is harmless.

And ofcourse, we should definitely add a note about this new flavour support in UPDATING, so users who want CANNA support don't have to build the port by themselves, and can just use a editors/emacs@canna package.

What do you say ?

P.S. Thank you for working on this.

This revision now requires changes to proceed.Jan 15 2018, 11:18 AM

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 ?
  1. 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.
  1. 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!

mat added a comment.Jan 15 2018, 2:55 PM

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.

  1. 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.)

editors/emacs/Makefile
48 ↗(On Diff #37636)

No, adding back the CANNA option is a bad idea. Using flavors is the way to go forward. An UPDATING entry saying how to get the -canna version is a better idea.

In D13506#291664, @mat 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.

  1. 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).

Mk/Uses/emacs.mk
77 ↗(On Diff #37636)

@jrm --- how about we change it to EMACS_FLAVOR?= ${FLAVOR} that way user can override it in make.conf(5), as remember to specifying FLAVOR explicitly for emacs dependent port seems pretty inconvenient for me, and this way it will be similar to older method ? We'll just have to add an UPDATING note that instead of EMACS_PORT_NAME, use EMACS_FLAVOR to specify your desired version of Emacs.

jrm added inline comments.Jan 16 2018, 2:05 PM
Mk/Uses/emacs.mk
77 ↗(On Diff #37636)

EMACS_FLAVOR is only for dependencies and does not affect the current port, so EMACS_FLAVOR?= ${FLAVOR} won't give what you are looking for. I will have to give this some thought to see if something can be done to address your point.

mat added a comment.Jan 16 2018, 2:20 PM

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

jrm added a comment.Jan 16 2018, 2:26 PM
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?

mat added a comment.Jan 16 2018, 2:51 PM

@ 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.

jrm added a subscriber: bapt.EditedJan 16 2018, 11:50 PM

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,....

jrm updated this revision to Diff 38074.Jan 17 2018, 3:40 AM
  • Permit default Emacs flavor to be specified in make.conf

Example: DEFAULT_VERSIONS=emacs=lite

jrm added a comment.Jan 17 2018, 3:42 AM

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.

mat added a comment.Jan 17 2018, 11:31 AM
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.

jrm updated this revision to Diff 38267.Jan 21 2018, 4:40 AM
  • editors/emacs-devel: Update to the latest upstream commit
  • Rename the lite Emacs flavor to nox [1]
  • Do not exclude the ACL option for the nox Emacs flavors
  • Remove editors/emacs-nox11
  • Turn off unwanted features in configure stage for lite Emacs package flavors
  • Minor whitespace changes in the Emacs ports
  • Add an UPDATING entry for the Emacs ports framework update

[1] Use a more appropriate name that matches the package name on some other operating systems.

ashish accepted this revision.Jan 21 2018, 11:35 PM

Looks good to me. Can be committed.

Thank you!

jrm updated this revision to Diff 38298.Jan 22 2018, 4:28 AM

Update dates in MOVED and editors/emacs-devel and tweak UPDATING entry

ashish added inline comments.Jan 22 2018, 1:16 PM
UPDATING
28 ↗(On Diff #38298)

Maybe also add an explicit note about editors/emacs-nox11 port being removed in favour of nox flavor, and above mentioned command-line can be used to install a non-X11 version of Emacs.

Also any idea how upgrade will work ? Like whether folks need to use pkg set -o ... or something, or portmaster -o ... ?

jrm updated this revision to Diff 38309.Jan 22 2018, 2:36 PM
  • Explicitly state that editors/emacs-nox11 has been removed in UPDATING entry.
jrm added inline comments.Jan 22 2018, 2:40 PM
UPDATING
28 ↗(On Diff #38298)

RE: upgrading, based on past changes and older MOVED entries, I assumed this would be transparent for package users. However, on one host that still had the emacs25-25.3_1,3 package installed, a pkg upgrade did not replace it with the new emacs-25.3_2,3. I will have to do some investigation.

mat added inline comments.Jan 22 2018, 3:01 PM
Mk/Uses/emacs.mk
33 ↗(On Diff #38309)

But the default flavor can be something else than "full", when using the default versions thing. No ?

84 ↗(On Diff #38309)

Maybe append the list of supported flavors here.

jrm updated this revision to Diff 38336.Jan 23 2018, 1:47 AM

Describe installation steps in UPDATING entry and address mat's latest comments

jrm marked an inline comment as done.Jan 23 2018, 1:49 AM
jrm added inline comments.
Mk/Uses/emacs.mk
33 ↗(On Diff #38309)

This variable is redundant now. I removed it.

jrm added a comment.Jan 23 2018, 3:09 AM

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

mat added a comment.Jan 23 2018, 1:53 PM

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

jrm updated this revision to Diff 38354.Jan 23 2018, 2:57 PM

Update maintainer to emacs@ in Mk/Uses/emacs.mk, editors/emacs, and editors/emacs-devel

jrm added a comment.Jan 26 2018, 3:05 PM
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?

mat added a comment.Jan 26 2018, 5:09 PM

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.

jrm updated this revision to Diff 38490.Jan 26 2018, 6:44 PM
  • fix confict between emacs/w3m and www/w3m
  • do not include Mk/bsd.emacs.mk in Mk/bsd.port.mk
  • update dates MOVED and UPDATING
mat accepted this revision.Feb 1 2018, 1:21 PM
mat added inline comments.
Mk/Uses/emacs.mk
2 ↗(On Diff #38490)

This is not really bsd.emacs.mk any more ;-)

21–22 ↗(On Diff #38490)

use DEFAULT_VERSIONS+=.

27–29 ↗(On Diff #38490)

I wonder if this should not be reversed, like, the "the list of flavors that I cannot build with". So that if a flavor is added later, it can be built too. (It is just a thought, not a request.)

This revision is now accepted and ready to land.Feb 1 2018, 1:21 PM
jrm added a comment.Feb 1 2018, 6:44 PM

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.

mat added a comment.Feb 1 2018, 11:03 PM
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.

jrm added a comment.EditedFeb 2 2018, 12:01 AM

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
mat added a comment.Feb 2 2018, 8:07 AM
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
This revision was automatically updated to reflect the committed changes.