libnewt

[tlesher@…]

I have patches for building libnewt on Mac OS X. Tested on 10.6, although I don't see a reason why this would not work on earlier versions.

Newt is a terminal-based menu system. It is required for using the Asterisk Project's menuselect interface on normal (80x24) terminals.

I do not have a portfile at this time, but it should be relatively straightforward.

[tlesher@…]

To apply against ​https://fedorahosted.org/releases/n/e/newt/ version 0.52.11

[ryandesign (Ryan Carsten Schmidt)]

Your patch hardcodes /opt/local; you must arrange to use the current value of ${prefix}. See PortfileRecipes.

Why do you prepend some commands with "echo" in this patch? Why not just remove those lines?

[tlesher@…]

Patch revised for the purpose of getting it submitted upstream to Fedora project

[tlesher@…]

Actually, my patch only hardcodes the use of /opt/local for the purpose of finding existing packages. It still uses ${prefix} for the installation of the binaries, libraries, and header files.

[ryandesign (Ryan Carsten Schmidt)]

Um, now the patch is almost 5000 lines long.

[tlesher@…]

Right, but most of it is just auto-generated from configure.ac. I'm hoping that the patch will be incorporated eventually into the newt source upstream. Either patch performs the same duty, but the second one does it in a way that should remain compatible with the existing package, by correctly detecting parameters on the system and modifying the compile accordingly.

[tlesher@…]

For cross-link reference: ​https://bugzilla.redhat.com/show_bug.cgi?id=652479

[tlesher@…]

newt-0.52.12-macosx.patch

[tlesher@…]

New patch applies against the latest newt release and also now correctly detects the location of libtcl.

[ryandesign (Ryan Carsten Schmidt)]

The attached portfile does not work. It does not use a patchfile, and there is no portgroup called "devel". Did you test the portfile before submitting?

I did not see your changes here as I was busy working on my own portfile, which I committed in r73485. I had to make many changes to your patch, both for conformance with MacPorts requirements and just to make the software build at all. The port still has many problems, but since I spent hours on it, I wanted to commit it before forgetting where I was. The remaining problems are:

• It finds all Apple-provided versions of Python, then installs files in the corresponding MacPorts versions of Python. The easiest fix is to disable all Python support in newt for now.
• The install_name of the libraries is wrong (does not include the complete path) so software using the libraries doesn't work.
• The filename of the libraries is wrong (uses Linux conventions like ending the library name with ".so" and putting the version number after the extension).

[tlesher@…]

Well, if you're satisfied with the patch and it's on track to being included in a release, then I'm fine with it. While I did not test the Portfile, as I'm unfamiliar with your build system, I did, in fact, test the patch, as I'm building against Asterisk, as Asterisk is my primary project, and the 'menuselect' binary builds and runs fine with libnewt. My primary interest in contributing the patch back was to ensure that others would not need to repeat my patch effort.

[jmroot (Joshua Root)]

Closing submission ticket as port has been added. Open new tickets for issues with it.

[ryandesign (Ryan Carsten Schmidt)]

Just to follow up on where we are:

Replying to ryandesign@…:

• It finds all Apple-provided versions of Python, then installs files in the corresponding MacPorts versions of Python. The easiest fix is to disable all Python support in newt for now.

To clarify: I did already disable python support in the port.

• The install_name of the libraries is wrong (does not include the complete path) so software using the libraries doesn't work.

Rainer fixed this in r76856.

• The filename of the libraries is wrong (uses Linux conventions like ending the library name with ".so" and putting the version number after the extension).

This issue remains.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

• The filename of the libraries is wrong (uses Linux conventions like ending the library name with ".so" and putting the version number after the extension).

Fixed for libnewt at least in r85050.