Ipe Discuss Pkg For Mac

It is best to consider that OS X is just a unix machine. The best way for compiling ipe, until recently, has been to hack src/config.mak and treat OS X just like an ordinary unix machine.

The Basics RELATED: Homebrew is a package manager designed for installing UNIX tools and other open-source applications on Mac OS X. Ipe-discuss Pkg For Mac Download Ipe-discuss Pkg For Mac Os Ipe-discuss Pkg For Mac Pro $ docker run hello-world Unable to find image \'hello-world:latest\'.

Just about every package available for Debian/Ubuntu/RHEL/etc. Is available on OS X by typing a command that is no longer than the equivalent one for Debian and co. It is very irritating to find that the last few releases of Ipe can all but not be compiled on OS X because the source files are inundated with halfhearted attempts at remedying one problem or another. Please make it possible for us to intentionally misspell \'MACOS\' and \'Darwin\' in the source files in one or a few places and henceforth OS X would be seen like a unix machine. Compilation is then entirely trivial. One just needs to have already installed Qt4 (. If you change \'Darwin\' in line 19 of \'common.mak\' to something else, compilation will proceed as if it\'s a normal Unix machine.

Compilation will then use \'config.mak\' and \'pkg-config\', not the special configuration file \'macos.mak\'. You may have to disable the special JPEG reading code in ipelib/ipebitmapunix.cpp, too. If this doesn\'t work, you can file a real bug report instead of whining about \'inundated with halfhearted attempts\'.Apparently you think that running Ipe inside a macports or homebrew environment is the only real way of using a Mac. Sorry, but you are a minority. Most Ipe users on Mac just want something they can install and that will run, without having to install Macports, XQuartz, or a developer package for Qt. My sources are such that I can compile such a bundle for normal Mac users.

And a normal Mac - without Macports - is really quite different from a Unix system.If you want to treat your Mac as a Linux machine with a funny user interface, that\'s your choice. Why would I have to go to any effort to support that?

The last version compiles very easily on Mac if you just follow the installation instructions. If you don\'t want to do that, you must be prepared to spend some effort. Even though - as I said above - just disabling recognition of Darwin should mostly work.pkg-config may work for you because you set it up right - in general it\'s a mess, because you never know if you get the native one, the one from homebrew, the one from macports, and very often something is broken. And nobody stops any user from calling pkg-config from config.mak. It\'s called \'config.mak\' because YOU are supposed to configure the compilation process.

I would be curious to know what your problems with compiling Ipe are. Are you perhaps trying to compile the newest version using an outdated Macports recipe?Compiling Ipe on Mac OS is easy. As you say, you can easily install the few dependencies (libpng, libcairo, freetype, Qt), using macports, XQuartz, or otherwise.Once you have them, you set the correct flags in \'macos.mak\' (you are free to simply use pkg-config there, if it works on your system), and say \'make\'.Ipe does not try to bundle or manage Qt, texlive, or any other dependency in any way. I have no idea why you suggest that \'These are massive packages that are best managed separately from Ipe\' - of course, and Ipe does not do any such thing. Ipe simply links against them and works with whatever package you provided.Perhaps your bug report is for the Macports recipe, not Ipe itself - but then it is entirely in the wrong place.

And really, one doesn\'t need a Macports recipe to compile Ipe, especially when one already has the necessary libraries installed through Macports. I\'m not sure why you insist on not using the MACOS setting in the Makefiles (common.mak). It does only two things: Use macos.mak instead of config.mak (but you could just copy your settings to that file instead), and set the right compilation and linking flags for OS X (you do that manually now anyway).By default, \'macos.mak\' sets the IPEBUNDLE variable, which will nicely package all files into an Ipe.app bundle. That\'s required if you want to run Ipe from the Finder, but you can of course unset the variable, install Ipe into /usr/local, and use Ipe only from the command line.Since 7.1.8, Ipe no longer uses the turbojpeg API. So you can simply link with -ljpeg using the libjpeg from macports. Turbojpeg is not needed.In fact, on OS X Ipe would normally simply use the faster native function for decoding JPEG images.

That\'s what the lines FRAMEWORKS?= /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/FrameworksJPEGCFLAGS?= -I$(FRAMEWORKS)/CoreGraphics.framework/Versions/A/Headers/JPEGLIBS?= -framework ApplicationServicesin macos.mak are for. But it seems you prefer to disable this in ipebitmapunix.cpp.The compilation error is inside a Qt 5 system header file - it\'s not finding qsizepolicy.h. So it would seem some include directory is missing. Some of the header files refer to other header files with a directory name, e.g.QWidget does #include, but then qwidget.h does #include. So the directory containing qsizepolicy.h should be named QtWidgets and must also be on the include search path. Is there such a directory?You could compile one of the examples included with the Qt SDK and check what paths it uses.Or just create the directories by making symbolic links: cd /usr/local/Qt5.4.2/5.4/clang64/lib/ln -s. QtWidgets.framework/Versions/5/Headers/QtWidgetsln -s.

QtGui.framework/Versions/5/Headers/QtGuiln -s. All right, success. Thanks for your help.It turns out that pkg-config is indeed broken on Qt—I asked on the Qt-interest mailing list. That remains the case in Qt 5.5.1. The following works on both Qt 5.4.2 and 5.5.1.I needed to modify macos.mak. A package manager is essential for Linux, because files are installed all over the system.Without a package manager to keep track of which file belongs to which program, you would becompletely unable to uninstall software or to track dependencies.This doesn\'t apply to OS X, since applications are installed in self-contained bundles, at leastif you follow Apple\'s architecture - so I think the need for a package manager issomewhat overstated.

You are right, fontmap.xml has been completely useless for a while. It is only needed whenPDF files do not contain embedded fonts (which is legal for the 14 standard PDF fonts, whichevery PDF processing software must provide itself). At least since Texlive 2013 the defaultsetup of Texlive does embed even these standard fonts, so there is no more need for Ipeto find the fonts elsewhere. The next version of Ipe for OS X uses Cocoa directly, not Qt. This means the install instructions for macports users will become very simple: Quickstart using Macports-.

Ipe needs the libraries libpng, libcairo, freetype, and lua. Ifyou have macports (www.macports.org), you can install these easilyby saying:sudo port install libpng lua cairo freetype. Compile Ipe by saying:cd srcmakemake app. Ipe is now available as a MacOS app in \'build/Ipe.app\'.Macports is severe overkill for this application, though. Starting from a fresh install of El Capitan, I installed macports and then said sudo port install libpng lua cairo freetype.

Afterwards, my /opt/local tree used more than 800 MB, the compilation took ages.When I compile libpng, lua, cairo, and freetype myself from sources (mostly very easy, just say configure & make), the Ipe dependencies fit in less than 10 MB. As you seem to be reading this issue thread, I will just add my current problems, and comments here:. Regarding MacPorts:. The MacPorts ipe version relies on Qt4 (not the x11 version), since there were issues with Qt5 last time I checked.

The Qt4/5 status in MacPorts is tricky and changing. My /opt/local tree uses several GB. It is the philosophy of MacPorts to reinstall a version of every dependency, even if it is already provided by Apple. The reason is that this tremendously eases support for different versions of OSX. After a while, pre-compiled versions of the main dependencies get cached, so installation remains fairly fast. Just for ipe, this is certainly overkill. But I have all my OSS (scientific python stack, octave, gcc, gimp, mpv (media player), latex.) managed by MacPorts, so for me this is not an issue.

If you rely on MacPorts to provide the dependencies for ipe, I don\'t see why you would not just install ipe via MacPorts as well. For most users, a precompiled binary for OSX is probably the most convenient, though. Current compilation issues:.

The current macos.mak seems to be tailored to a very specific and non-standard setup, and is probably not very useful for general compilation on OSX (as noted by the OP). The config.mak file is very clear and much better suited, even on OSX.

The way you include CoreGraphics is AFAIK not correct, but I am not an expert. I think you should #include instead of #include.

Then you don\'t need any include compiler directives, but only need to add -framework ApplicationServices to the library flags. (Please check this, though, since I am not sure.). The ipelets/lua/Makefile causes my install to fail (at least with IPEBUNDLE unset). Perhaps the condition should be ifdef IPEBUNDLE instead of ifdef MACOS?. General comments:.

Your above \'very simple installation instructions\' give me the chills. First of all, sudo port install ipe is certainly much simpler. But apart from this, why the heck would I want ipe bundled in an Ipe.app?

I want to type ipe and use it. If I wanted to go clicking around first, I would be using Windows. Pleeease at least keep an option to just compile and install ipe to an IPEPREFIX as is possible now. Note that such an install can still be wrapped by an Ipe.app for convenience, if desired (this is what the MacPort version does).

Thanks for all your great efforts! Ipe is a fantastic little piece of software:-). Okay, let\'s reopen this as long as there is some discussion. I didn\'t say that macports was bad and I understand why you use it. I was just pointing out that just to compile Ipe, it\'s heavy overkill. My own limited experience with macports is rather bad - after installing the Ipe dependencies, I wanted to install one more package - and the build immediately failed. If Ipe uses Qt4 for Mac rather than for X11, why does then list qt4-x11 as a dependence?

But I\'m glad to hear it\'s not actually using this - in any case I don\'t want to worry about Qt anymore, and I\'m not using it on OS X starting from the next release. When I provide a Makefile for a platform, it should build a program according to the architecture of the platform. For OS X, the architecture is clear: applications are built as stand-alone bundles. So the default compilation for OS X must built such a bundle.

It\'s as easy as this.I don\' t understand you concern that somehow having the Ipe binary in /opt/local/bin is \'better\' than having it in /Applications/Ipe.app/Contents/MacOS. These are just conventions.As for \'clicking around\', I always use Ipe and its associated tools from the command line. Simply add /Applications/Ipe.app/Contents/MacOS to your path, and you are all set. (As for \'I would be using Windows\' - from my experience with bug reports on the different platforms, the average OS X user is even more clueless than the average Windows user. Apple tries hard to keep their users uneducated.). What is the exact error you get in ipelets/lua? It seems to me that the default target is all and should do nothing.

The installation instructions are for somebody who wants to compile Ipe. I assume people who simply want to install through macports know how to type \'sudo port install ipe\' and don\'t need instructions for that. So the instructions are meant for somebody who wants to compile Ipe without doing this - there are many reasons, e.g.

Wanting the newest version for which a portfile is not yet available. The right thing to do in this situation is building a bundle. It\'s self-contained, can be used immediately, moved around, installed in /Applications, and can be removed or replaced by a newer version at a keystroke. It would be immensely foolish to somehow try to build into /usr/local (impossible on new OS X anyway) or into /opt/local (clobbering up the macports installation). I believe macos.mak already says: If you don\'t want to build a bundle, undefine IPEBUNDLE and define all the variables from config.mak. Essentially you are already doing this, except that you also decided to use libjpeg rather than Apple\'s native optimized jpeg code.However, I\'m not sure how well this is going to work starting with the next release, as my understanding is that Cocoa finds its resources (e.g.

Mainmenu.nib) inside the bundle which is defined by the path of the executable. I\'m sure you\'ll figure it out:-) You could always compile against Qt and forgo the Cocoa-based improvements, I guess, in exchange for knowing that Ipe is where it belongs in /opt/local/bin.

Hi there,.MacPorts ipe depends on qt4-mac. The dependency is set based on an internal variable os.platform. If this is darwin, then qt4-mac is selected, otherwise qt4-x11. : \'So whoever is maintaining the Ipe MacPort would help a lot by providing, in addition to or instead of, the Ipe MacPort with the full dependencies another Ipe MacPort that depends on neither texlive nor on Qt.\' I am sorry, but even if I waned to, MacPorts will not allow such a port (using externally installed Qt), since it goes against the MacPorts idea of essentially providing all dependencies from within MacPorts (for maintainability reasons). Note that the MacPorts ipe port has never (explicitly) depended on MacPorts texlive, though, but perhaps some dependency chain brought this in, I don\'t know.On modern hardware, I don\'t feel that this is really much of an issue anyway. Also, MacPorts now has a (currently not functioning) system to provide precompiled binaries, and with this in place, installation is basically as fast as apt-get install.

On linux.Out of curiosity, I just moved my MacPorts to the side and did a complete reinstall from scratch, setting the default variants to -x11 +nox11 +quartz in /opt/local/etc/macports/variants.conf, and did sudo port install ipe. This took a total of 52 minutes, of which 21 were spent building qt4-mac. The resulting /opt/local directory is 1.5 GB (which I can get down to 1 GB by removing stuff only required during the build). To be honest, I think this is not that bad. \'This took a total of 52 minutes,. I think this is not that bad. \'Maybe not - I didn\'t know about these cool flags.

Do they stop macports from adding all the weird dependencies to Cairo?But honestly, why would anyone want to install Ipe through macports? Starting in the next release, the binary package for Ipe will be small and completely self-contained. It no longer needs Qt, and contains compact builds of lua, libpng, libfreetype, and libcairo.In the past, installing Ipe through macports was useful, because the binary Mac package often came out much after new sources, and until 7.1.9 the binary package assumed you had X11 installed (a huge dependency).

The binary package was also big because it contained the Qt monster, so by installing through macports you could share the macports Qt installation.None of this will be true starting from the next release. Binary Mac packages are released at the same time as the sources, they are small, and entirely self-contained.Some people may want to make changes to Ipe and therefore want to compile themselves. But if you install through macports, you can\'t even do that. Is there any reason why someone might prefer to install Ipe through macports?

The -x11 variant of cairo gets rid of the X11 dependencies (xrender, xorg-libXext, xorg-xcb-util). I have other software that really does require these, though, but it is useful if you can avoid X11 dependencies altogether. However, precompiled binaries, once available again, will only be provided for the default port variants.In the past, installing Ipe through macports was useful, because the binary Mac package often came out much after new sources, and until 7.1.9 the binary package assumed you had X11 installed (a huge dependency). The binary package was also big because it contained the Qt monster, so by installing through macports you could share the macports Qt installation.\'

And back in 2010 as I recall there was no binary version for OSX (or very outdated). From then on, just maintaining the MacPorts port for ipe has not been that much effort.Starting in the next release, the binary package for Ipe will be small and completely self-contained.

It no longer needs Qt, and contains compact builds of lua, libpng, libfreetype, and libcairo.Binary Mac packages are released at the same time as the sources, they are small, and entirely self-contained.Agreed, this will indeed be a great service to us OSX users, and at that point installing through MacPorts or homebrew becomes much less interesting. Will you be supporting older versions of OSX as well?So now I am very curious about the next ipe release:-). If you have a look at the Preview.app, it does have two toolbars, one named \'Markup Toolbar\'. Also, most OSX apps seem to allow customization of the toolbar. It makes a lot of sense if it is so restricted to choose your most important tools yourself.

It is best to consider that OS X is just a unix machine. The best way for compiling ipe, until recently, has been to hack src/config.mak and treat OS X just like an ordinary unix machine.

The Basics RELATED: Homebrew is a package manager designed for installing UNIX tools and other open-source applications on Mac OS X. Ipe-discuss Pkg For Mac Download Ipe-discuss Pkg For Mac Os Ipe-discuss Pkg For Mac Pro $ docker run hello-world Unable to find image \'hello-world:latest\'.

Just about every package available for Debian/Ubuntu/RHEL/etc. Is available on OS X by typing a command that is no longer than the equivalent one for Debian and co. It is very irritating to find that the last few releases of Ipe can all but not be compiled on OS X because the source files are inundated with halfhearted attempts at remedying one problem or another. Please make it possible for us to intentionally misspell \'MACOS\' and \'Darwin\' in the source files in one or a few places and henceforth OS X would be seen like a unix machine. Compilation is then entirely trivial. One just needs to have already installed Qt4 (. If you change \'Darwin\' in line 19 of \'common.mak\' to something else, compilation will proceed as if it\'s a normal Unix machine.

Compilation will then use \'config.mak\' and \'pkg-config\', not the special configuration file \'macos.mak\'. You may have to disable the special JPEG reading code in ipelib/ipebitmapunix.cpp, too. If this doesn\'t work, you can file a real bug report instead of whining about \'inundated with halfhearted attempts\'.Apparently you think that running Ipe inside a macports or homebrew environment is the only real way of using a Mac. Sorry, but you are a minority. Most Ipe users on Mac just want something they can install and that will run, without having to install Macports, XQuartz, or a developer package for Qt. My sources are such that I can compile such a bundle for normal Mac users.

And a normal Mac - without Macports - is really quite different from a Unix system.If you want to treat your Mac as a Linux machine with a funny user interface, that\'s your choice. Why would I have to go to any effort to support that?

The last version compiles very easily on Mac if you just follow the installation instructions. If you don\'t want to do that, you must be prepared to spend some effort. Even though - as I said above - just disabling recognition of Darwin should mostly work.pkg-config may work for you because you set it up right - in general it\'s a mess, because you never know if you get the native one, the one from homebrew, the one from macports, and very often something is broken. And nobody stops any user from calling pkg-config from config.mak. It\'s called \'config.mak\' because YOU are supposed to configure the compilation process.

I would be curious to know what your problems with compiling Ipe are. Are you perhaps trying to compile the newest version using an outdated Macports recipe?Compiling Ipe on Mac OS is easy. As you say, you can easily install the few dependencies (libpng, libcairo, freetype, Qt), using macports, XQuartz, or otherwise.Once you have them, you set the correct flags in \'macos.mak\' (you are free to simply use pkg-config there, if it works on your system), and say \'make\'.Ipe does not try to bundle or manage Qt, texlive, or any other dependency in any way. I have no idea why you suggest that \'These are massive packages that are best managed separately from Ipe\' - of course, and Ipe does not do any such thing. Ipe simply links against them and works with whatever package you provided.Perhaps your bug report is for the Macports recipe, not Ipe itself - but then it is entirely in the wrong place.

And really, one doesn\'t need a Macports recipe to compile Ipe, especially when one already has the necessary libraries installed through Macports. I\'m not sure why you insist on not using the MACOS setting in the Makefiles (common.mak). It does only two things: Use macos.mak instead of config.mak (but you could just copy your settings to that file instead), and set the right compilation and linking flags for OS X (you do that manually now anyway).By default, \'macos.mak\' sets the IPEBUNDLE variable, which will nicely package all files into an Ipe.app bundle. That\'s required if you want to run Ipe from the Finder, but you can of course unset the variable, install Ipe into /usr/local, and use Ipe only from the command line.Since 7.1.8, Ipe no longer uses the turbojpeg API. So you can simply link with -ljpeg using the libjpeg from macports. Turbojpeg is not needed.In fact, on OS X Ipe would normally simply use the faster native function for decoding JPEG images.

That\'s what the lines FRAMEWORKS?= /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/System/Library/FrameworksJPEGCFLAGS?= -I$(FRAMEWORKS)/CoreGraphics.framework/Versions/A/Headers/JPEGLIBS?= -framework ApplicationServicesin macos.mak are for. But it seems you prefer to disable this in ipebitmapunix.cpp.The compilation error is inside a Qt 5 system header file - it\'s not finding qsizepolicy.h. So it would seem some include directory is missing. Some of the header files refer to other header files with a directory name, e.g.QWidget does #include, but then qwidget.h does #include. So the directory containing qsizepolicy.h should be named QtWidgets and must also be on the include search path. Is there such a directory?You could compile one of the examples included with the Qt SDK and check what paths it uses.Or just create the directories by making symbolic links: cd /usr/local/Qt5.4.2/5.4/clang64/lib/ln -s. QtWidgets.framework/Versions/5/Headers/QtWidgetsln -s.

QtGui.framework/Versions/5/Headers/QtGuiln -s. All right, success. Thanks for your help.It turns out that pkg-config is indeed broken on Qt—I asked on the Qt-interest mailing list. That remains the case in Qt 5.5.1. The following works on both Qt 5.4.2 and 5.5.1.I needed to modify macos.mak. A package manager is essential for Linux, because files are installed all over the system.Without a package manager to keep track of which file belongs to which program, you would becompletely unable to uninstall software or to track dependencies.This doesn\'t apply to OS X, since applications are installed in self-contained bundles, at leastif you follow Apple\'s architecture - so I think the need for a package manager issomewhat overstated.

You are right, fontmap.xml has been completely useless for a while. It is only needed whenPDF files do not contain embedded fonts (which is legal for the 14 standard PDF fonts, whichevery PDF processing software must provide itself). At least since Texlive 2013 the defaultsetup of Texlive does embed even these standard fonts, so there is no more need for Ipeto find the fonts elsewhere. The next version of Ipe for OS X uses Cocoa directly, not Qt. This means the install instructions for macports users will become very simple: Quickstart using Macports-.

Ipe needs the libraries libpng, libcairo, freetype, and lua. Ifyou have macports (www.macports.org), you can install these easilyby saying:sudo port install libpng lua cairo freetype. Compile Ipe by saying:cd srcmakemake app. Ipe is now available as a MacOS app in \'build/Ipe.app\'.Macports is severe overkill for this application, though. Starting from a fresh install of El Capitan, I installed macports and then said sudo port install libpng lua cairo freetype.

Afterwards, my /opt/local tree used more than 800 MB, the compilation took ages.When I compile libpng, lua, cairo, and freetype myself from sources (mostly very easy, just say configure & make), the Ipe dependencies fit in less than 10 MB. As you seem to be reading this issue thread, I will just add my current problems, and comments here:. Regarding MacPorts:. The MacPorts ipe version relies on Qt4 (not the x11 version), since there were issues with Qt5 last time I checked.

The Qt4/5 status in MacPorts is tricky and changing. My /opt/local tree uses several GB. It is the philosophy of MacPorts to reinstall a version of every dependency, even if it is already provided by Apple. The reason is that this tremendously eases support for different versions of OSX. After a while, pre-compiled versions of the main dependencies get cached, so installation remains fairly fast. Just for ipe, this is certainly overkill. But I have all my OSS (scientific python stack, octave, gcc, gimp, mpv (media player), latex.) managed by MacPorts, so for me this is not an issue.

If you rely on MacPorts to provide the dependencies for ipe, I don\'t see why you would not just install ipe via MacPorts as well. For most users, a precompiled binary for OSX is probably the most convenient, though. Current compilation issues:.

The current macos.mak seems to be tailored to a very specific and non-standard setup, and is probably not very useful for general compilation on OSX (as noted by the OP). The config.mak file is very clear and much better suited, even on OSX.

The way you include CoreGraphics is AFAIK not correct, but I am not an expert. I think you should #include instead of #include.

Then you don\'t need any include compiler directives, but only need to add -framework ApplicationServices to the library flags. (Please check this, though, since I am not sure.). The ipelets/lua/Makefile causes my install to fail (at least with IPEBUNDLE unset). Perhaps the condition should be ifdef IPEBUNDLE instead of ifdef MACOS?. General comments:.

Your above \'very simple installation instructions\' give me the chills. First of all, sudo port install ipe is certainly much simpler. But apart from this, why the heck would I want ipe bundled in an Ipe.app?

I want to type ipe and use it. If I wanted to go clicking around first, I would be using Windows. Pleeease at least keep an option to just compile and install ipe to an IPEPREFIX as is possible now. Note that such an install can still be wrapped by an Ipe.app for convenience, if desired (this is what the MacPort version does).

Thanks for all your great efforts! Ipe is a fantastic little piece of software:-). Okay, let\'s reopen this as long as there is some discussion. I didn\'t say that macports was bad and I understand why you use it. I was just pointing out that just to compile Ipe, it\'s heavy overkill. My own limited experience with macports is rather bad - after installing the Ipe dependencies, I wanted to install one more package - and the build immediately failed. If Ipe uses Qt4 for Mac rather than for X11, why does then list qt4-x11 as a dependence?

But I\'m glad to hear it\'s not actually using this - in any case I don\'t want to worry about Qt anymore, and I\'m not using it on OS X starting from the next release. When I provide a Makefile for a platform, it should build a program according to the architecture of the platform. For OS X, the architecture is clear: applications are built as stand-alone bundles. So the default compilation for OS X must built such a bundle.

It\'s as easy as this.I don\' t understand you concern that somehow having the Ipe binary in /opt/local/bin is \'better\' than having it in /Applications/Ipe.app/Contents/MacOS. These are just conventions.As for \'clicking around\', I always use Ipe and its associated tools from the command line. Simply add /Applications/Ipe.app/Contents/MacOS to your path, and you are all set. (As for \'I would be using Windows\' - from my experience with bug reports on the different platforms, the average OS X user is even more clueless than the average Windows user. Apple tries hard to keep their users uneducated.). What is the exact error you get in ipelets/lua? It seems to me that the default target is all and should do nothing.

The installation instructions are for somebody who wants to compile Ipe. I assume people who simply want to install through macports know how to type \'sudo port install ipe\' and don\'t need instructions for that. So the instructions are meant for somebody who wants to compile Ipe without doing this - there are many reasons, e.g.

Wanting the newest version for which a portfile is not yet available. The right thing to do in this situation is building a bundle. It\'s self-contained, can be used immediately, moved around, installed in /Applications, and can be removed or replaced by a newer version at a keystroke. It would be immensely foolish to somehow try to build into /usr/local (impossible on new OS X anyway) or into /opt/local (clobbering up the macports installation). I believe macos.mak already says: If you don\'t want to build a bundle, undefine IPEBUNDLE and define all the variables from config.mak. Essentially you are already doing this, except that you also decided to use libjpeg rather than Apple\'s native optimized jpeg code.However, I\'m not sure how well this is going to work starting with the next release, as my understanding is that Cocoa finds its resources (e.g.

Mainmenu.nib) inside the bundle which is defined by the path of the executable. I\'m sure you\'ll figure it out:-) You could always compile against Qt and forgo the Cocoa-based improvements, I guess, in exchange for knowing that Ipe is where it belongs in /opt/local/bin.

Hi there,.MacPorts ipe depends on qt4-mac. The dependency is set based on an internal variable os.platform. If this is darwin, then qt4-mac is selected, otherwise qt4-x11. : \'So whoever is maintaining the Ipe MacPort would help a lot by providing, in addition to or instead of, the Ipe MacPort with the full dependencies another Ipe MacPort that depends on neither texlive nor on Qt.\' I am sorry, but even if I waned to, MacPorts will not allow such a port (using externally installed Qt), since it goes against the MacPorts idea of essentially providing all dependencies from within MacPorts (for maintainability reasons). Note that the MacPorts ipe port has never (explicitly) depended on MacPorts texlive, though, but perhaps some dependency chain brought this in, I don\'t know.On modern hardware, I don\'t feel that this is really much of an issue anyway. Also, MacPorts now has a (currently not functioning) system to provide precompiled binaries, and with this in place, installation is basically as fast as apt-get install.

On linux.Out of curiosity, I just moved my MacPorts to the side and did a complete reinstall from scratch, setting the default variants to -x11 +nox11 +quartz in /opt/local/etc/macports/variants.conf, and did sudo port install ipe. This took a total of 52 minutes, of which 21 were spent building qt4-mac. The resulting /opt/local directory is 1.5 GB (which I can get down to 1 GB by removing stuff only required during the build). To be honest, I think this is not that bad. \'This took a total of 52 minutes,. I think this is not that bad. \'Maybe not - I didn\'t know about these cool flags.

Do they stop macports from adding all the weird dependencies to Cairo?But honestly, why would anyone want to install Ipe through macports? Starting in the next release, the binary package for Ipe will be small and completely self-contained. It no longer needs Qt, and contains compact builds of lua, libpng, libfreetype, and libcairo.In the past, installing Ipe through macports was useful, because the binary Mac package often came out much after new sources, and until 7.1.9 the binary package assumed you had X11 installed (a huge dependency).

The binary package was also big because it contained the Qt monster, so by installing through macports you could share the macports Qt installation.None of this will be true starting from the next release. Binary Mac packages are released at the same time as the sources, they are small, and entirely self-contained.Some people may want to make changes to Ipe and therefore want to compile themselves. But if you install through macports, you can\'t even do that. Is there any reason why someone might prefer to install Ipe through macports?

The -x11 variant of cairo gets rid of the X11 dependencies (xrender, xorg-libXext, xorg-xcb-util). I have other software that really does require these, though, but it is useful if you can avoid X11 dependencies altogether. However, precompiled binaries, once available again, will only be provided for the default port variants.In the past, installing Ipe through macports was useful, because the binary Mac package often came out much after new sources, and until 7.1.9 the binary package assumed you had X11 installed (a huge dependency). The binary package was also big because it contained the Qt monster, so by installing through macports you could share the macports Qt installation.\'

And back in 2010 as I recall there was no binary version for OSX (or very outdated). From then on, just maintaining the MacPorts port for ipe has not been that much effort.Starting in the next release, the binary package for Ipe will be small and completely self-contained.

It no longer needs Qt, and contains compact builds of lua, libpng, libfreetype, and libcairo.Binary Mac packages are released at the same time as the sources, they are small, and entirely self-contained.Agreed, this will indeed be a great service to us OSX users, and at that point installing through MacPorts or homebrew becomes much less interesting. Will you be supporting older versions of OSX as well?So now I am very curious about the next ipe release:-). If you have a look at the Preview.app, it does have two toolbars, one named \'Markup Toolbar\'. Also, most OSX apps seem to allow customization of the toolbar. It makes a lot of sense if it is so restricted to choose your most important tools yourself.