xxdiff: update to 4.0

[RJVB (René Bertin)]

Attached is a diff that updates the xdiff portfile to use the latest version, 4.0 (which builds against qt4-mac). I've moved the documentation (that includes a series of screenshots) to a +doc variant.

[cooljeanius (Eric Gallager)]

Heh, and I just installed the version that uses qt3 today, too... anyways, the diff should be of the unified type (i.e. diff -u).

[cooljeanius (Eric Gallager)]

Cc Me!

[RJVB (René Bertin)]

Replying to egall@…:

Heh, and I just installed the version that uses qt3 today, too... anyways, the diff should be of the unified type (i.e. diff -u).

Yeah, the other flavours don't work, eh?

Check again O:-)

[ryandesign (Ryan Carsten Schmidt)]

Some observations:

• One should not both declare "use_configure no" and define a "configure" block.
• Do you really need to override the configure phase to run qmake? The point of the qmake 1.0 portgroup is to automate that for you.
• One should not "system "cd ...; ...""; one should instead "system -W ... "..."".
• "file copy" can be shortened to "copy" and "file delete" can be shortened to "delete".
• Is there a reason why the documentation needs to be moved to a doc variant? Variants should be added sparingly and when absolutely necessary.

[RJVB (René Bertin)]

Replying to ryandesign@…:

• One should not both declare "use_configure no" and define a "configure" block.

OK.

• Do you really need to override the configure phase to run qmake? The point of the qmake 1.0 portgroup is to automate that for you.

Have you checked the previous (v3) xxdiff Portfile as well as the port's README.build? A bare-bones qmake won't work.

• One should not "system "cd ...; ...""; one should instead "system -W ... "..."".

If you say so ... but I'd prefer to read up on the 'system' documentation before changing something I left unchanged from the v3 xxdiff Portfile (if not only because your suggestion is too ambiguous to my taste; should I understand the syntax is system -W workDirectory "command args"?) I'll wait for clarification before uploading a new Portfile diff.

• "file copy" can be shortened to "copy" and "file delete" can be shortened to "delete".

OK

• Is there a reason why the documentation needs to be moved to a doc variant? Variants should be added sparingly and when absolutely necessary.

As I tried to indicate, the documentation contains a number of screenshots that take up more space than I considered justified for something I expect no one will ever read. Many ports already provide a +doc variant, I hope exactly to reduce disk space usage. IMHO it's something that should be generalised just like Debian and Ubuntu now split off the documentation of most all packages into separate packages.

[mf2k (Frank Schima)]

Replying to rjvbertin@…:

Replying to ryandesign@…:

• One should not "system "cd ...; ...""; one should instead "system -W ... "..."".

If you say so ... but I'd prefer to read up on the 'system' documentation before changing something I left unchanged from the v3 xxdiff Portfile (if not only because your suggestion is too ambiguous to my taste; should I understand the syntax is system -W workDirectory "command args"?) I'll wait for clarification before uploading a new Portfile diff.

Yes, you can read the FAQ about it.

[RJVB (René Bertin)]

Uploaded the modified Portfile diff. I've added 2 patchfiles, one to correct a minor issue in the parser yacc source, and one to add a few keyboard accelerators (which I'd defined through the SystemPreferences before with a non-MacPorts build of the same source).

Building the package on Linux, I discovered that resParser.y must be adapted for use with bison 3.0x . I don't know if/when MacPorts will upgrade bison to the v3 series, but when that happens a patch must be found. I am not familiar with these tools, sadly, or I'd do it right now.

[cooljeanius (Eric Gallager)]

Replying to rjvbertin@…:

Building the package on Linux, I discovered that resParser.y must be adapted for use with bison 3.0x . I don't know if/when MacPorts will upgrade bison to the v3 series, but when that happens a patch must be found. I am not familiar with these tools, sadly, or I'd do it right now.

The ticket for the update to bison3 is #41600
The ticket that resulted from the last time we tried updating to bison3 is #39910

[RJVB (René Bertin)]

I see the latter ticket has portfiles for building bison 2.7 and 3.0, but they haven't yet made it to MacPorts?

[RJVB (René Bertin)]

It's taken a while, but here's an update that takes into account the latest xxdiff upstream changes and (most of?) the critiques above. In addition, I managed to get the application to build with Qt5 (5.4.1 from my port:qt5-mac-devel) which allows (me :)) to use xxdiff on a remote X11 display too.

Track ​https://github.com/RJVB/mp-port-repository/tree/master/devel/xxdiff for further changes.

[RJVB (René Bertin)]

this is ${filespath}/patch-xxdiffpro.diff ; patch-xxdiffpro.2.diff should be called ${filespath}/qt5/patch-xxdiffpro.diff !

[kurthindenburg (Kurt Hindenburg)]

Cc Me!

[kurthindenburg (Kurt Hindenburg)]

I'm getting this w/ the qt4 version - I cloned your github to verify I had the correct patches.

../xxdiff-4.0/src/resParser.cpp:40:10: fatal error: 'resParser_lex.h' file not found
#include <resParser_lex.h>

[RJVB (René Bertin)]

Issue with how qmake generates the build rules; raised upstream a while ago already, nothing I can do about it.

The Qt5 version isn't affected but I haven't verified if it builds against the current port:qt5-mac .

[mkae (Marko Käning)]

@RJVB, what's the status here?

Should be superseded by a PR, no?

[chrstphrchvz (Christopher Chavez)]

Latest xxdiff is 4.0.1 (released 2016)

[panewt]

Tonight (23jun19) I installed MacPorts on Mojave and tried to install xxdiff. It failed regarding qt3. Searching in MacPorts, I found #57350 which made it obvious that qt3 is "the past" and this ticket seems to indicate that there is a remedy for such.

However, this ticket says that "2 days ago" the "Latest xxdiff is 4.0.1 (released 2016)". When I query tonight's install of MacPorts for "port search xxdiff", it tells me "xxdiff @3.2.1 (devel)".

What am I missing to not allow me to get the above referenced xxdiff 4.0.1 with qt4 thorough MacPorts?

Thanks for any and all advice

[RJVB (René Bertin)]

What you are missing is that the changes proposed in this ticket were never integrated, and I have basically abandoned it in favour of my own fork (and custom port).

The official 4.0.1 version does have most of my contributions included, so it should be straightforward for you to check out the sources and then build them against the required dependents from your MacPorts install. if you do, I'd strongly suggest to build against Qt5.

[panewt]

Rene:

Thank you for the back-story on this. It would seem like xxdiff ought to be removed from MacPorts on Mojave if it can't be installed, but maybe I am missing something here.

I did as you suggested and aside from a few warnings (including the resParser_lex.h mentioned above), it compiled successfully. And I did use qt5 as you suggested. One small gotcha is that MacPort installed qmake at /opt/local/libexec/qt5/bin but does not adjust the PATH nor puts up a "note" after installing. Easy to adjust PATH but a bit of a waste of time figuring out "why it isn't there"

The latest version I found on Martin Blais' site at bitbucket.org is dated 22jun17 and has no version info. When built, it says it is 5.0b1. If I had read the commits better, I would have seen he bumped to 5.0 beta in November 2016. If I had know the latest was a beta (as in "my bad" for not reading), I probably would have tried to find the last 4.x version. But I figure I'll deal with it if/when I see a problem. I must admit, over 2 years in beta with no changes in 2 years is interesting.

I note that it appears to no longer need XQuartz as earlier versions did.

And, yes, it was relatively straightforward which was appreciated. The most time consuming part was taking notes in case something did go wrong.

Once again, my thanks for your help

[RJVB (René Bertin)]

You don't need to worry about the 5 "beta" status, the application works as well with Qt5 as it did with Qt4. Probably better (faster) and more reliably on such a recent OS where Qt4 is likely to start showing its age and lack of updates. In fact, the "5 beta" version is just the stable 4.x release with the minimum changes required to make it build against Qt5. I think Martin is a bit like me in that he probably forgets about details such as version numbers when software just works.

I did make a few more tweaks to my own version but nothing that I felt needed "upstreaming".

One small gotcha is that MacPort installed qmake at /opt/local/libexec/qt5/bin but does not adjust the PATH nor puts up a "note" after installing. Easy to adjust PATH but a bit of a waste of time figuring out "why it isn't there"

Well, that's port:qt5 and its maintainer for you. As you say it would have been easy to make the Qt4 qmake available directly (as qmake-qt5 for instance like many Linux distros do, or via Qt's own qtchooser utility). That's not the only aspect where a more convenient way of installing things would not have been that hard. The background here is that MacPorts couldn't install Qt4 and Qt5 concurrently for a long time, and when that became untenable (and I had invested a lot of work in creating nicely adaptations for both ports) the 2 maintainers each decided on the blunt and safe method of installing all of Qt in a dedicated prefix (e.g. /opt/local/libexec/qt5).

[panewt]

Rene:

Thanks for clarification about "beta" status and that it is really just 4.x with qt5. As for the use of a "dedicated prefix", the maintainers need to make the call as to the way they want to do it but they really ought to add a note at the end of the install about what they did and the need for the user to adjust their PATH.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 966a8dcbf65898371e47565e19b16e7c3629d483/macports-ports (master):

xxdiff: update version 3.2->4.0.1

Fixes #44526