Bug 203471 - New port: editors/e The minimalistest text editor
Summary: New port: editors/e The minimalistest text editor
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Alexey Dokuchaev
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2015-10-01 12:08 UTC by Jens K. Loewe
Modified: 2015-11-17 11:50 UTC (History)
1 user (show)

See Also:


Attachments
The e port (2.05 KB, text/plain)
2015-10-01 12:08 UTC, Jens K. Loewe
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jens K. Loewe 2015-10-01 12:08:55 UTC
Created attachment 161597 [details]
The e port

I just found some editor on GitHub and thought I'll make it a port.
Comment 1 Bert Burgemeister 2015-10-03 07:37:31 UTC
The editor doesn't work for me.  The only key chord that does anything useful seems to be ^C, which terminates the program.
Comment 2 Jan Beich freebsd_committer 2015-10-24 04:58:42 UTC
(Hand over to danfe@ as "In Progress" is invalid without Assignee)

Other than comment 1 there're lots of style bugs as well.

$ portlint -AC
FATAL: Makefile: [3]: use a tab (not space) after a variable name
FATAL: Makefile: [4]: use a tab (not space) after a variable name
FATAL: Makefile: [5]: use a tab (not space) after a variable name
FATAL: Makefile: [6]: use a tab (not space) after a variable name
FATAL: Makefile: [8]: use a tab (not space) after a variable name
FATAL: Makefile: [9]: use a tab (not space) after a variable name
FATAL: Makefile: [11]: use a tab (not space) after a variable name
FATAL: Makefile: [12]: use a tab (not space) after a variable name
FATAL: Makefile: [14]: use a tab (not space) after a variable name
FATAL: Makefile: [15]: use a tab (not space) after a variable name
FATAL: Makefile: [16]: use a tab (not space) after a variable name
FATAL: Makefile: [18]: use a tab (not space) after a variable name
FATAL: Makefile: [19]: use a tab (not space) after a variable name
FATAL: Makefile: [20]: use a tab (not space) after a variable name
WARN: Makefile: COMMENT should begin with a capital, and end without a period
14 fatal errors and 1 warning found.

>XPORTVERSION=  1.0
[...]
>XGH_TAGNAME=   2dffcf1c7245142c8bfc813641a5467f6300bf08

Marking a random commit as 1.0 may lead you to bump PORTEPOCH in future if upstream create a tag with lower version e.g., 0.4. Better prepend a few zeros then use the date of the commit e.g., 0.0.20141210.

>XDIST_SUBDIR=  e

This is not necessary as USE_GITHUB makes filenames unique enough, see distinfo.

>XCOMMENT=      e is the minimalistest text editor

"e is the" should be dropped to avoid redundancy.

>XUSE_GCC=      yes

USE_GCC is an implementation detail. Unless it doesn't build for a valid reason (e.g. bug in a compiler, another port or hard to fix) drop or convert to USES=compiler. Clang errors are often verbose enough to tell you how to fix them:

  e.c:84:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
  unsigned int main(register unsigned int argc, char* argv[]) {
  ^
  e.c:84:1: note: change return type to 'int'
  unsigned int main(register unsigned int argc, char* argv[]) {
  ^~~~~~~~
  int
  e.c:84:14: error: first parameter of 'main' (argument count) must be of type 'int'
  unsigned int main(register unsigned int argc, char* argv[]) {
               ^
  1 warning and 1 error generated.

>Xpost-extract:
>X	@${MV} ${WRKSRC}/makefile ${WRKSRC}/Makefile

Define MAKEFILE instead.

>Xpost-patch:
>X	@${REINPLACE_CMD} -e 's/gcc/${CC}/' ${WRKSRC}/Makefile

Don't use / separator with variables that may contain paths.

  $ make CC=/usr/local/bin/clang37
  ===>  Applying FreeBSD patches for e-1.0
  sed: 1: "s/gcc//usr/local/bin/cl ...": bad flag in substitute command: 'u'
  *** Error code 1

>X+all:
>X	gcc ./e.c ./codes.c -o e

No respect for CFLAGS/LDFLAGS/LIBS ? Either adjust above post-patch or replace "all" target e.g.,

  # Provides both "all" and "install" targets
  USES=		uidfix
  MAKEFILE=	/usr/share/mk/bsd.prog.mk
  MAKE_ENV=	PROG=${PORTNAME} NO_MAN= BINDIR="${PREFIX}/bin" \
  		SRCS="`${ECHO_CMD} *.c`"

https://www.freebsd.org/doc/en/books/porters-handbook/dads-cflags.html

>X+
>X+install: all
>X+	mkdir -p $(DESTDIR)$(PREFIX)/bin/
>X+	install -m 755 e $(DESTDIR)$(PREFIX)/bin/
>X+

If you don't plan to upstream "install" target then move installation into the port. For one, it'd take care of stripping non-debug builds for you.

https://www.freebsd.org/doc/en/books/porters-handbook/install.html#install-strip
Comment 3 Jan Beich freebsd_committer 2015-10-24 05:04:52 UTC
Second try. Hand over to danfe@ for clarification. "In Progress" is invalid without Assignee.
Comment 4 Alexey Dokuchaev freebsd_committer 2015-10-24 14:24:48 UTC
Excuse me?  Since when "In Progress" is invalid without assignee?  In progress means that some work/research was done about proposition and reflected in the audit trail (comments).  It really helps to distinguish such ports from truly new.

It does require to have particular committer to be assigned to it.  Thanks for forcing me to deal with this PR. :-(
Comment 5 Alexey Dokuchaev freebsd_committer 2015-11-17 11:50:08 UTC
After reading its description on the GitHub page (https://github.com/the8thbit/e) I now feel that this "editor" does not really have its place in the Ports Collection, sorry Jens.

It has very little practical value (the goal was to "distill the concept of a text editor down to its bare minimum", quoting the author), while it is fun project and idea to explore, it does not match the burden of maintaining it as part of the Ports Tree.  If someone wants it, they can easily build it from source code and install locally (it does not come with or expect any data or configuration files found anywhere, obviously).

FreeBSD Ports Collection is not the place for everyone's "helloworlds" or otherwise purely experimental/just-for-fun projects.