org-mode enhancements to support Emacs.app and optional contrib modules

[jrhope]

Here is a Portfile patch which adds two new variants: app, which enables building with Emacs.app, and contrib, which enables installation of most of the optional modules in contrib/lisp.

The only contrib module which is not installed by the contrib variant is org-jira.el, because it has a build-time dependency on jira.el (a file which is not available via MacPorts and so is most likely not available). It may be desirable to break this up into multiple variants which each only enable one or a few of the contrib files, but as a start it seemed most useful to do as many as possible. (The definition of ORG_ADD_CONTRIB is broken up as it is in order to keep line lengths short.)

The app variant implementation is borrowed from the slime package. It basically just has to replace the name of the Emacs binary used to do byte compilation (and make the required depends_lib change).

[mf2k (Frank Schima)]

In the future, please Cc the port maintainer(s).

For displaying text to the user, the use of system "echo... should be replaced by the Macports notes command.

[jrhope]

Replying to macsforever2000@…:

In the future, please Cc the port maintainer(s).

Will do. Somebody might want to add that to ​http://guide.macports.org/#project.contributing.updates

For displaying text to the user, the use of system "echo... should be replaced by the Macports notes command.

I'm not displaying any text to the user. I'm adding text to the end of the file local.mk

[mf2k (Frank Schima)]

Replying to jrh@…:

Will do. Somebody might want to add that to ​http://guide.macports.org/#project.contributing.updates

This is already in the ​ticket reporting guidelines. I agree it could written be more clearly.

I'm not displaying any text to the user. I'm adding text to the end of the file local.mk

OK. Sorry for my misunderstanding.

[jrhope]

Here's an alternate patch (v2) which does not create the +app variant. Instead, it first looks for the Emacs.app binary, and if that fails then it automatically falls back to the emacs binary. This is how the gnuplot port does it, and I think it's a more elegant solution. If I have installed emacs-app via MacPorts, then other Emacs-using ports should transparently accept it as a suitable Emacs binary without forcing me to manually set a variant or redundantly install emacs.

[drkp (Dan Ports)]

(sorry for the delay with this; I am travelling but should be able to take care of this in a day or two...)

[drkp (Dan Ports)]

Hmm, I think

depends_lib         path:${prefix}/share/emacs/site-lisp:emacs 

doesn't quite work; there are some packages that will install into site-lisp even if emacs isn't installed, which would allow them to satisfy the dependency.

We'll need to do something closer to what the gnuplot port is doing, and this would probably be a good time to refactor that into a portgroup...

I'm also not thrilled about using a combination of wildcards in ORG_ADD_CONTRIB to exclude org-jira; that will need to be updated when new contrib modules are added to make sure they're included too.

[jrhope]

Replying to dports@…:

Hmm, I think

depends_lib         path:${prefix}/share/emacs/site-lisp:emacs 

doesn't quite work; there are some packages that will install into site-lisp even if emacs isn't installed, which would allow them to satisfy the dependency.

All we really care about is that ${prefix}/share/emacs/site-lisp exists so we can put files there. If it doesn't exist, then the emacs package will create it; if it does exist, then we're already good.

I guess we also implicitly assume that there's some Emacsen available to compile, but that could be optional as well. (I've seen some packages, like slime, that couldn't get compilation to work so they just install the .el files and don't worry about it.) Otherwise, do something like

set org_mode_emacs_binary "${applications_dir}/Emacs.app/Contents/MacOS/Emacs"
if {![file exists $org_mode_emacs_binary] {
    set org_mode_emacs_binary "${prefix}/bin/emacs"
}
set emacs_provider [registry_file_registered $org_mode_emacs_binary]
if {$app_provider == 0} {
  depends_build-append path:bin/emacs:emacs
} else {
  depends_build-append port:${app_provider}
}

We'll need to do something closer to what the gnuplot port is doing, and this would probably be a good time to refactor that into a portgroup...

I think that's an excellent idea. I also have no idea what's involved in accomplishing it, technically or politically.

I'm also not thrilled about using a combination of wildcards in ORG_ADD_CONTRIB to exclude org-jira; that will need to be updated when new contrib modules are added to make sure they're included too.

Yeah, it's not ideal. I just didn't want to create a separate variant for each file in contrib, and wasn't sure how to easily construct a Make variable representing "everything in contrib except org-jira". We basically need something like the value of

`cd ${worksrcpath}/contrib && ls *.el | cut -d "." -f 1 | grep -v org-jira | tr "\n" " "`

stored in the variable ORG_ADD_CONTRIB in ${worksrcpath}/local.mk. Portfiles are TCL scripts, right? What are the quoting rules? Can you put all of that stuff between backticks inside of a 'system' call?

[drkp (Dan Ports)]

See #39019 for a proposed portgroup with the logic for supporting emacs-app...

[drkp (Dan Ports)]

Added support for emacs-app (with the new portgroup) in r106036.

[drkp (Dan Ports)]

...and added the +contrib variant in r106061. Sorry this took so long!