Mac OSX usage and volunteering

I would like to use graphviz on a mac to report on certain values overlaid on a graph. It mentions on the website that mac volunteers are needed for development, I’d like to connect with someone about the details of the requirements.

2 Likes

Hi, thank you for your interest in working on this.

OK stream of consciousness, someone can help to organize this into a plan. The immediate need is to get automated builds and packaging working again. Currently, the Xcode build generates Graphviz.app and probably the command line tools, too. It is run from old style Makefiles in graphviz/macosx/build You can see the debris of older Makefiles there as well. I believe the interactive Xcode GUI still builds, too, but the Makefiles enable us to compile it as part of a CI pipeline. I am not sure if there is even a more tasteful way to make that happen. At this point we lack any way to put Graphviz.app into a .pkg or .dmg which seems to be how OSX programs are shipped. I did some experiments to get pkgbuild working, and it did not seem hard. But I’m not convinced this would handle relocation correctly, if graphviz is not installed in /Applications. As pointed out, we also don’t have a certificate to sign the software for Graphviz to be trusted for an installation and I’m not sure we merit that much trust anyway.

Finally, in the distant past, I believe we put the command line tools in Graphviz.app/Contents/MacOS/bin (with a corresponding lib nearby) and then symlinked this into /usr/local. I realize this was an abuse of power but wonder if there are decent alternatives.

I also wondered about just scarfing up builds from Homebrew, and, er, doing something. Or we could bail on this and advise our audience to use Homebrew.

Stephen North

1 Like

Ok, I will attempt to build in xcode, this is pretty new to me, so it will take a bit of time, but glad to assist. I believe packages like Apollo are migrating to swift scripting. Are there documents that indicate what the path structures are for developers?

2 Likes

So, the current source (general, not Mac-specific) builds without much drama in OSX Catalina / Xcode 12.4.

Then, cd macosx; cp Makefile.mountainlion Makefile; make and Release/Graphviz.app results and can be executed. Test graphs display.

The make process exits prematurely because the now-sunsetted OSX PackageMaker utility isn’t installed.

Is there a way to generate a Mac pkg or dmg using packagebuild? That would be nice for people.

Is this exercise pointless because we don’t have a developer’s license and a way to sign the resulting package?

Should the Graphviz.app build process be simplified? it seems to run (cd …/…; make) first. Also, we have no need of the prebuild environment any more. This dates from pre-Homebrew pre-Macports days when we installed and built our own copies of everything from glib to cairopango.

Stephen

The following seems to be almost a replacement for PackageMaker in macosx/build/Makefile.* It needs minor tweaking: run a postinstall script; the version number needs to come from the build system; I don’t think /System/Library/User is right; need to remove Release/Graphviz.app.dSYM or prevent it from being packaged.

pkgbuild --analyze --root Release graphviz.install.plist
pkgbuild --identifier org.graphviz.graphviz.pkg  \
        --component-plist graphviz.install.plist \
         --version 3.01 \
         --root Release \
         --install-location /System/Library/User \
         ~/tmp/Graphviz.pkg

Other massive cleanup seems possible, since the local gmake Makefile (yet another build system) now runs the autotools make from scratch in the parent directory. Instead Graphviz.app should be integrated into the rest of the build, probably using CMake.

So, are there currently any step-by-step instructions for how a non-XCode-developer can get a working copy of graphviz on Mojave? The Homebrew version does not work at all, and building from scratch creates binaries that only segfault, even on fairly small graphs.

Doesn’t anyone just have a binary they can share instead of making the users jump through many hours of endless hoops that ultimately don’t even work? I’ve spent several days now on trying to get this to work with absolutely nothing to show for the time. Not a single one of the “solutions” easily found online actually works.

I even tried omnigraffle, which seems to use a nonstandard version of Dot and errors out on standard Dot files rather than generating the graph.

I currently have an important project which unfortunately relied on graphviz and is now toast because the Dot-formatted output apparently is no longer possible to render into a visual graph by any means on Mac.

If your looking for SVG output and you have NodeJS installed, you can try:

npx -p @hpcc-js/wasm dot-wasm "digraph { a->b }"

npx -p @hpcc-js/wasm dot-wasm --help for all options

The gitlab CI includes a MacOS build, kindly donated by gitlab. I don’t understand the details of the CI any more, but it’s there, e.g.

Someday it might be used to package the release possibly using pkgbuild

I work on a MacBook, Monterey == MacOS 12.4 and build the source from gitlab. I have a ton of Homebrew packages, all the way from pango, cairo an d ghotsview down to glib. Also Xcode.

Usually,

./autogen.sh, 
OBJC=clang CC=clang CXX=clang++  CXXFLAGS=-std=gnu++17 ./configure --verbose --with-x11 --with-extralibdir=/usr/local/opt/gettext/lib --with-extraincludedir=/usr/local/opt/gettext/include --prefix=/Users/north --with-quartz --with-pangocairo --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib --with-ann=yes --with-extralibdir=/usr/local/lib --with-extraincludedir=/usr/local/include --with-ipsepcola --enable-php=no
make install

The command line tools build right now. I’m not sure how many of the config options are still needed.

If I can make time later, I’ll try to finish the Graphviz.app build and package a copy.

Just to add one further thing, after removing macosx/build/SharedPrecompiledHeaders the MacOS Graphviz.app build pretty much goes through until the packaging stage (which I can finish by hand) but the package no longer contains command line tools. Maybe they are essentially useless now as it would be pretty questionable to link from Graphviz.app/Contents/Resources/MacOS over to /usr/local/something but what’s the alternative?

What do other tools do? I should look into TeXLive or something like it that must face the same problem.

I don’t know how Mojave maps to macOS version numbers, but as Stephen said there are CI jobs for macOS that build an apparently working binary. You can see how this is done by looking at the scripts in ci/ in the repository, ci · main · graphviz / graphviz · GitLab. The ones you most likely want to look at are:

  • build.sh
  • install-packages.sh
  • macos-install-build-dependencies.sh
  • macos-install-runtime-dependencies.sh

You could also ask either the Homebrew or Macports Graphviz maintainers who are generally pretty proactive in pulling in the latest Graphviz releases.

Edit: sorry, I missed you already said the Homebrew version is busted. You may want to report this to them as they may not realize.

Hi,

Wanted to share a quick update regarding the Mac install and linking instruction.
I was able to get the Mac-os setup functional with pythons bindings.

Use Case: use graphviz in a Jupiter notebook with miniconda python3.8 interpreter.

In this case I’ve used home-brew to install the application.

brew install graphviz

While the pip version of the python bindings resulted in a Posix path error, the conda version did not have such issues. And so, the easy work around is to install anaconda or miniconda as your environment manager.

conda install python-graphviz

Here’s an existing GitHub issue that helped me.

Reference:

  1. "failed to execute ['dot', '-Tsvg'], make sure the Graphviz executables are on your systems' PATH" error on platform · Issue #68 · xflr6/graphviz · GitHub
1 Like

I came back to check up because I’m now over 6 months without an essential tool over this.

I read through all the links since my last post, followed all the links, and all of them ended in either an error or no instructions on how to proceed all the way to a working graphviz installation.

npx -p @hpcc-js/wasm dot-wasm "digraph { a->b }"

…spits out a bunch of errors

GitLab

macos-autotools-test (#2585593410) · Jobs · graphviz / graphviz · GitLab 4

…I have no idea what this page is. I poked around that site and did find a couple of binary downloads, all of which segfault when I run them.

ci · main · graphviz / graphviz · GitLab 6

…I can’t figure out what this page is suggesting I do.

conda install python-graphviz

…does a bunch of stuff and then apparently does not provide a working install of Graphviz, or at least, not one that I can find or figure out how to run. I did figure out how to activate a virtual env, and then dot seems available according to which dot but again, all running a proper dot command does within this env is give a segfault.

Which brings us to the present day with still no working Graphviz for Mojave.

Does nobody have either simple step-by-step instructions to get graphviz working on Mojave, or, much better, a download of a working binary? Mojave is a very standardized platform, SIP keeps all Mac OS installs the same, if just one single person on the planet builds a binary for Mojave, shouldn’t that binary be good for everyone else? I have web space, I’d be happy to host it myself.

I install graphviz for mac through homebrew

http://brew.sh/

Then

$ brew install graphviz

$ dot -h

I understand that this is still unresolved. The building of Graphviz on a Mac still doesn’t work. Correct?

As far as I know, it does. We have macOS CI jobs that are passing.

Indeed! I can compile it on my Mac. Great. Well done guys!
The only missing part is that I needed to install a new Bison version and add it to the bash
echo 'export PATH="/opt/homebrew/opt/bison/bin:$PATH"' >> ~/.zshrc

one problem remains: debug is properly created (like libcgraph.a (see (1) in the below picture), the release side creates an alias only (2), pointing at the location of the alias (3).

I had a look, the compilation happens for release as well. Even the libraries are created, just the last step of creating a universal library and placing it in the output directory is missing. Any idea why?