[61108] trunk/dports/_resources/port1.0/group/muniversal-1.0.tcl

[Jeremy Huddleston]

Why don't we just stop shipping .la files?  They don't actually do ANYTHING useful.


On Dec 10, 2009, at 12:19, Ryan Schmidt wrote:

> Jeremy, allow me to bring this to the macports-dev list...
> 
> On Dec 10, 2009, at 13:23, Jeremy Huddleston wrote:
> 
>> On Dec 1, 2009, at 19:34, ryandesign at macports.org wrote:
>> 
>>> Revision: 61108
>>>        http://trac.macports.org/changeset/61108
>>> Author:   ryandesign at macports.org
>>> Date:     2009-12-01 19:34:12 -0800 (Tue, 01 Dec 2009)
>>> Log Message:
>>> -----------
>>> muniversal-1.0.tcl: compare contents of compressed files, not the compressed files themselves; see #22650
>> 
>> I think you may have broken muniversal with this change.  See attached log for installing tiff.
>> 
>> <main.log>
> 
>> :debug:destroot Backtrace: /opt/local/lib/libtiff.la differs in /opt/local/var/macports/build/_Users_jeremy_src_macports-trunk_dports_graphics_tiff/work/destroot-i386 and /opt/local/var/macports/build/_Users_jeremy_src_macports-trunk_dports_graphics_tiff/work/destroot-x86_64 and cannot be merged
> 
> That wasn't because of r61108, but because of r61090. And that revision wouldn't have broken tiff or any other port; that revision merely causes MacPorts to notify you that tiff +universal is already broken. Before, you would've gotten a broken .la file without knowing it. muniversal tries to merge files using C/C++ preprocessor directives, which are not appropriate for .la files or .pc files or -config scripts. muniversal previous assumed those types of files would never differ. Sometimes they do. So r61090 now actively prevents those files from being merged. See #21953 for the long list of related confusing issues that had previously been caused by not having this in place.
> 
> This change will probably reveal many ports that have been broken all along. For example a ticket was filed for pango +quartz +universal. I don't know how to fix it but now we at least prevent users from installing software that they think is working properly when it really isn't.
> 
> In the case of tiff, though, it installs fine for me. So I would be interested for you to show me how libtiff.la differs between your two destroots. Could you send me those two libtiff.la files, or run a diff -ru between your two destroots and see how they (and perhaps other files) differ? One common reason why such files might differ is if one of the dependencies (jpeg, zlib) wasn't built universal. If that's the reason here, we could add archcheck to tiff to prevent it in the future.
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5820 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20091210/6b78c925/attachment.bin>