Building on MacOS -- instructions about domterm HOT 23 OPEN

Try setting the value command.electron in your settings.ini (see http://domterm.org/Settings.html) to the location of the electron executable.

If there is a default/standard location for electron on MacOS, we can put it in the electron_command procedure inlws-term/server.c. (If electron is normally in the PATH, then that should be enough.)

from domterm.

I wrote up preliminary build instructions at http://domterm.org/Downloading-and-building.html based on your report and that of another contributor (who helped me fix various portability problems).

from domterm.

from domterm.

Do you have pkg-config installed? If not, could you try with it installed? What do you get for pkg-config --cflags openssl and pkg-config --libs openssl?

See the code in configure.ac starting with if pkg-config openssl. That is supposed to set the right includes and libraries.

from domterm.

from domterm.

What do you think of the following patch:
config-patch.txt

Will that allow us to drop the explicit setting of LDFLAGS/CFLAGS/CPPFLAGS?

from domterm.

I tried the following (like above),

brew install automake json-c libwebsockets asciidoctor

export LDFLAGS="-L/usr/local/opt/openssl/lib -L/usr/local/lib -L/usr/local/opt/expat/lib"
export CFLAGS="-I/usr/local/opt/openssl/include/ -I/usr/local/include -I/usr/local/opt/expat/include"
export CPPFLAGS="-I/usr/local/opt/openssl/include/ -I/usr/local/include -I/usr/local/opt/expat/include"
export PKG_CONFIG_PATH=/usr/local/opt/openssl/lib/pkgconfig/

./configure make

but it results in an error:

❯ ./configure make
configure: WARNING: you should use --build, --host, --target
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for a BSD-compatible install... /usr/local/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/local/bin/gmkdir -p
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... Invalid configuration `make': machine `make' not recognized
configure: error: /bin/sh autotools-aux/config.sub make failed

Any ideas?

from domterm.

The "./configure make" in the initial post is misleading. These are separate commands:

./configure
make

Please read these detailed build instructions. Let us know if you run into problems.

from domterm.

Oh, I see, ./configure and make are suppose to be different commands. That wasn't very obvious from the initial post above.

Now ./configure seems to work, but I see a bunch of output like the following repeated many times:

asciidoctor -b manpage doc/help/domterm.adoc -o - \
	  | man -l --nj --nh - \
	  | /usr/bin/sed -e '1,3d' -e '4s/^ *//' -e '$d' > share/domterm/help/domterm.txt
man: invalid option -- l
man, version 1.6c

usage: man [-adfhktwW] [section] [-M path] [-P pager] [-S list]
	[-m system] [-p string] name ...

  a : find all matching entries
  c : do not use cat file
  d : print gobs of debugging information
  D : as for -d, but also display the pages
  f : same as whatis(1)
  h : print this help message
  k : same as apropos(1)
  K : search for a string in all pages
  t : use troff to format pages for printing
  w : print location of man page(s) that would be displayed
      (if no name given: print directories that would be searched)
  W : as for -w, but display filenames only

  C file   : use `file' as configuration file
  M path   : set search path for manual pages to `path'
  P pager  : use program `pager' to display pages
  S list   : colon separated section list
  m system : search for alternate system's man pages
  p string : string tells which preprocessors to run
               e - [n]eqn(1)   p - pic(1)    t - tbl(1)
               g - grap(1)     r - refer(1)  v - vgrind(1)

And looking at share/domterm/help/domterm.txt for example, I see it is empty. So that part isn't working on macOS.

from domterm.

Hmmm, a search for "man: invalid option -- l" turns up absolutely no results. 🤔 I suppose I can skip this for now, as it looks to be just docs.

from domterm.

You can avoid running asciidoctor if you add --without-asciidoctor to the confgure command:

./configure --without-asciidoctor

It might be possible to change man -l to use man -M PATH instead, but I'd have to see how that would work.

from domterm.

Yay, ./configure && make && make install worked! 👍

So just in case, for me on macOS, the exact thing that worked is:

brew install automake json-c libwebsockets asciidoctor

export LDFLAGS="-L/usr/local/opt/openssl/lib -L/usr/local/lib -L/usr/local/opt/expat/lib"
export CFLAGS="-I/usr/local/opt/openssl/include/ -I/usr/local/include -I/usr/local/opt/expat/include"
export CPPFLAGS="-I/usr/local/opt/openssl/include/ -I/usr/local/include -I/usr/local/opt/expat/include"
export PKG_CONFIG_PATH=/usr/local/opt/openssl/lib/pkgconfig/

./configure && make && make install

(the && is required!)

from domterm.

Question: now that I'm done building and I have the domterm executable in my PATH, is there anything post-install things I should clean up?

from domterm.

It might be possible to change man -l to use man -M PATH instead, but I'd have to see how that would work.

Cool. No biggie though, everything is working with no need (so far) to look at those docs.

from domterm.

You can do a make clean after make install.

Actually, make install isn't needed - you can run bin/domterm in-place (but in that case you shouldn't make clean).

You might consider downloading electron, if you haven't. That makes for a slightly nicer experience. See the instructions I linked to above. The electron executable needs to be in your PATH. If there is a standard place electron is installed in OS X, let me know, and I can change DomTerm to look for it there.

from domterm.

downloading electron

I'm using atom-domterm. :)

from domterm.

I get the same man error when building, but as mentioned, this can be ignored (for now).

I fail to use anything else than Firefox. When I run bin/domterm without options, it will use Firefox, which kind of works (I will do separate issues for the issues I encounter there).

Using bin/domterm --chrome gives me:

neither chrome or google-chrome command found

Of course, Chrome is installed, and even my default browser.

I edited ~/.domterm/settings.ini and added command.electron = ... there. Then bin/domterm --electron starts an Electron instance, but nothing happens. No window is opening.

(Not sure if these are OSX specific issues, or other problems. But maybe OSX related - that is why I posted them here in this thread.)

from domterm.

On MacOS, is chrome normally installed in a location not in the PATH? If there a "standard" installation location for chrome? If so we can hardwire that as a location to try, like we do for Firefox (in firefox_browser_command in lws_term/server.c).

See the chrome_command function in server.c. Perhaps you could suggest a patch?

IIRC I put in the getenv("CHROME_BIN") test for MacOS, but I guess it isn't something we can count on.

from domterm.

On OSX, no app is installed in PATH. They are all independent app bundles (usually in /Applications, but you can put them wherever you want), and you can optionally have a starter button in the dock.

However, there are multiple ways to find them independent from where they are, because they are registered globally. E.g. when in terminal, and you call open "http://www.google.com", the default browser would open that page. That works for any protocol and any file, and it starts the default app for that file type or protocol. You can do the same and specify the app name, e.g. open -a "Google Chrome" "http://www.google.com". You can also do the same and specify the app bundle id, e.g. open -b com.google.Chrome "http://www.google.com". The app bundle id is probably the most consistent and stable and safest way.

(I wonder, how does it find Firefox? That works currently.)

from domterm.

Looks like the default is "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome", so we could at least test for that.

The problem with open -b com.google.Chrome is how do we gracefully detect whether chrome is installed? When trying different browsers in turn (like chrome;firefox) we need a quiet way to detect that chrome is missing. This isn't quite as important when explicitly requested with a --chrome option, but I'm concern about domterm hanging with a confusing error message (or none). Is there a simple way to check if an app bundle is installed?

from domterm.

There are definitely very simple and clean ways to detect whether com.google.Chrome (or any app bundle) is installed or not (just check the documentation; or maybe see here; many more ways...). Probably open also returns a well-defined error code. Relying on such a common path on the other side is definitely a very bad idea. It's similar bad to always assume C:\Program Files\Google Chrome\Chrome.exe (or so) or /usr/bin/google-chrome.

from domterm.

I followed the instructions but when I execute bin/domterm -Belectron it opens an app called Electron with a transparent window that shows only the close, minimize buttons.

I want to use this terminal as I need the folding output feature

from domterm.

I just tried a rebuild using fresh souces, on macOS Monterey on an early-2015 MacBook Air and didn't notice any obvious problems.

That makes it hard for me to debug/reproduce. You could try one of the other front-ends: -Bqt, -Bwry, or even -Bsafari.

from domterm.