[73103] djview Lint Report

[Ryan Schmidt]

On Nov 4, 2010, at 06:51, Michael Dickens wrote:
> On Nov 3, 2010, at 11:44 PM, Ryan Schmidt wrote:
>> Due to this revision, the djview port does not work; attempting to use it produces the message quoted above.
>> 
>> If you want to use "archcheck.files" you need to include the archcheck 1.0 portgroup.
> 
> With this checkin, the qt4 portgroup was including the archcheck portgroup and then adding QtCore if not trying to build qt4 in the first place.  So, while it -looks- like the individual djview portfile is missing the archcheck portgroup, it is being included (just indirectly).  The Portfile does work, at least for me -- & my version of 'port' isn't very far out of SVN-date.  That said ...

Hm, I guess I had updated the djview port but not the qt4 portgroup, which is why I was seeing the problem.


>> I wrote the archcheck portgroup some time ago to ensure dependencies of a port were installed with the right architecture, both to help people trying to rebuild a port universal or with a different build_arch (and forgetting or not knowing that they have to rebuild dependencies that way first) and to help users upgrading to Snow Leopard (some of whom whom did not know they needed to uninstall and reinstall all ports on Snow Leopard).
>> 
>> As of MacPorts 1.9.0, both of these situations are now handled by MacPorts base itself -- if you install a port universal, it will rebuild dependencies universal for you, and MacPorts now records the architecture with which the port claims to build in the registry -- so the archcheck portgroup isn't really needed anymore, for ports whose dependencies have been upgraded after MacPorts 1.9.0 was released and where those dependencies properly respect universal_archs and build_arch.
>> 
>> In this revision, you added archcheck for libQtCore.dylib (provided by qt4-mac) and libdjvulibre.dylib (provided by djvulibre), both of which were updated recently, well after the release of MacPorts 1.9.0, so unless qt4-mac or djvulibre do not respect universal_archs or build_arch, this manual archcheck is not needed.
> 
> ... OK, I didn't know this functionality was pushed into 'port' itself -- I think it's good that it was, since IMHO it should be automagically executed with any given port.  Most of the qt4 ports are kept reasonably up to date, so I'm just going to remove archcheck from the qt4 portgroup & those ports I've just added it to.  Thanks for the quick reply & info. - MLD

That's probably best.

A lot of my ports still use the archcheck portgroup, mostly because I haven't taken the time to check whether it's safe to remove.

But the one nice thing the archcheck portgroup does, that MacPorts base doesn't do, is check the actual architectures of the installed files. MacPorts base only checks the architecture for which the port claims to have installed the files, which, if the port doesn't respect build_arch or universal_archs, for example, might not necessarily be the same thing.

Ideally MacPorts base would check, after the destroot phase, whether every file in the destroot has the architectures the port claims to have used, and if not, issue a warning. (It probably shouldn't be a terminal error, though, because I can think of at least one port that installs a precompiled ppc binary in addition to stuff built for the current architecture and we wouldn't want to prevent software like that from working.)