Autotools OSX PSFontDir Fiddling

[barak]

Added configure.ac autoconf code to check for places OSX puts fonts, and also to allow

./configure --with-PSFontDir=/this/is/the/place/with/my/fonts

There must be a "right" way to get font metrics, but for now I'm hoping this will get the autotools-based build system to work on OS X.

[vectaport]

Barak, I'm unable to get the generated configure script to find X11 libraries or includes. Even making symbolic links from standard Linux install directories doesn't work (it's under /opt/X11 on OS X). Thanks for working on the PostScript stuff, but I've simply forgotten how I worked around this problem before. It seems a vulnerability in either OS support or autotools versioning. More wrestling with GNU configuration software is not something I'm looking to do or support (Golang is such a breath of fresh air in this area). I think it fine given github that you maintain a permanent fork that Debianizes the source tree. As long as we can share valuable changes to the C++ code as they come up, by github or patch if need be. Does renaming the source files defeat the auto merge happiness of git? I considered renaming them myself (from .c to .cc) , but don't see the purpose at this point because I'm the only active developer I know of, and its no longer my main focus. I appreciate the work you do to make the drawing editors available within Debian's packaging system. I just don't think I have the bandwidth to make this pull request succeed. -Scott

[barak]

Let me answer the git question first: yes merging changes you make to foo.c into my branch in which I renamed foo.c to foo.cc works fine; this is a nice feature of git. However you might want to rename all the C++ files from .c to .cc anyway, for convenience of editors and to avoid confusing other automated tools, like making it easier to do a recursive diff between the C++ sources in your branch and my branch.

Even if we keep two build systems alive (which is fine with me; I just found the effort of getting xmkmf working in Debian and having the libraries generated with the right flags and such smaller than the effort of switching to autotools) it would be nice if the autotools version did work on OSX. I suppose I really should just round up a Mac which I could use. But I think I may have fixed in: just pushed a patch. Now these options

$ ./configure --help | egrep -A2 'X features'
X features:
  --x-includes=DIR    X include files are in DIR
  --x-libraries=DIR   X library files are in DIR

should actually work, and also might not be necessary.

Speaking of changes to the C++ code, you might want to consider 941ac44fd69cd9b4b19487479a7f15135e27b1c2.

[vectaport]

Barak,

I got much further that time, finding the X11 directories. The build made it quite far before running into an ACE related problem. How do I configure for ACE? How do I configure for not using ACE? —with-ace or —with-ACE didn’t work, and then I tried to complete the build without it, but -DHAVE_ACE is still defined, so missing ACE includes are pulled into the compile.

I’ve reopened your pull request. We might be able to work through this.

Scott

On May 7, 2015, at 2:41 AM, Barak A. Pearlmutter notifications@github.com wrote:

Let me answer the git question first: yes merging changes you make to foo.c into my branch in which I renamed foo.c to foo.cc works fine; this is a nice feature of git. However you might want to rename all the C++ files from .c to .cc anyway, for convenience of editors and to avoid confusing other automated tools, like making it easier to do a recursive diff between the C++ sources in your branch and my branch.

Even if we keep two build systems alive (which is fine with me; I just found the effort of getting xmkmf working in Debian and having the libraries generated with the right flags and such smaller than the effort of switching to autotools) it would be nice if the autotools version did work on OSX. I suppose I really should just round up a Mac which I could use. But I think I may have fixed in: just pushed a patch. Now these options

$ ./configure --help | egrep -A2 'X features' X features: --x-includes=DIR X include files are in DIR --x-libraries=DIR X library files are in DIR should actually work, and also might not be necessary.

Speaking of changes to the C++ code, you might want to consider 941ac44 https://github.com/vectaport/ivtools-1.2/commit/941ac44fd69cd9b4b19487479a7f15135e27b1c2.

— Reply to this email directly or view it on GitHub https://github.com/vectaport/ivtools-1.2/pull/2#issuecomment-99795692.

[vectaport]

And, yes, I’ll take 941ac44 https://github.com/vectaport/ivtools-1.2/commit/941ac44fd69cd9b4b19487479a7f15135e27b1c2. But I’m a little confused as how to pull it in (between the git command line, the github web page, and the github app). Is there a branch name associated with this? To me it looks like a commit made to vectaport/ivtools-1.2, not barak/ivtools-1.2. Can you make a pull-request for it?

I’m still on that github learning curve.

Scott

On May 7, 2015, at 2:41 AM, Barak A. Pearlmutter notifications@github.com wrote:

Let me answer the git question first: yes merging changes you make to foo.c into my branch in which I renamed foo.c to foo.cc works fine; this is a nice feature of git. However you might want to rename all the C++ files from .c to .cc anyway, for convenience of editors and to avoid confusing other automated tools, like making it easier to do a recursive diff between the C++ sources in your branch and my branch.

Even if we keep two build systems alive (which is fine with me; I just found the effort of getting xmkmf working in Debian and having the libraries generated with the right flags and such smaller than the effort of switching to autotools) it would be nice if the autotools version did work on OSX. I suppose I really should just round up a Mac which I could use. But I think I may have fixed in: just pushed a patch. Now these options

$ ./configure --help | egrep -A2 'X features' X features: --x-includes=DIR X include files are in DIR --x-libraries=DIR X library files are in DIR should actually work, and also might not be necessary.

Speaking of changes to the C++ code, you might want to consider 941ac44 https://github.com/vectaport/ivtools-1.2/commit/941ac44fd69cd9b4b19487479a7f15135e27b1c2.

— Reply to this email directly or view it on GitHub https://github.com/vectaport/ivtools-1.2/pull/2#issuecomment-99795692.

[barak]

First, the git question: assuming you have my repo as a remote, you can just

git cherry-pick 941ac44

but if you want I can generate a pull request that will have the same effect.

[barak]

When I remove libace-dev from my system and compile, the configuration scripts pick up on ACE being missing and do not define HAVE_ACE. But there are a lot of C++ errors, things like

   _addr = nil;
   _socket = nil;
   _conn = nil;

in src/ComTerp/ctrlfunc.cc not being guarded. And a zillion others.

They look like simple bit rot. I will add a stanza to to configure.ac to allow ./configure --without-ACE to make it easier to shake these out. Or, you can just require ACE and remove all those guards and that's that.

[vectaport]

Done. Thanks.

On May 7, 2015, at 1:07 PM, Barak A. Pearlmutter notifications@github.com wrote:

git cherry-pick 941ac44

[barak]

added a ./configure --without-ace option

[vectaport]

Attempted to test the --without-ace configure option, but now I need a --without-clippoly. Is there a way --without-ace and --without-clippoly could be made the defaults?

[barak]

@vectaport Does

./configure --without-ace --without-clippoly

work? The --with-ace, --with-clippoly and --with-tiff options should default to checking if the library in question is available and enabling or disabling depending on the result.

[vectaport]

Hope this is easy enough to keep maintained downstream.

Scott