[52182] trunk/dports/graphics/libart_lgpl

[Marcus Calhoun-Lopez]

I was the one with "bright idea" to make the "insane" changes you  
found objectionable.
Please allow me to explain my reasoning.

1) Getting a universal binary wrong (e.g. wrong sizeof(long)) can  
cause a very hard to track down bug.

2) Finding all the places where "#ifdef {__LP64__, i386, ppc}" are  
needed is time consuming, tedious, and error prone.
      It is not even a one time expense since the same process must be  
done with each version.
      It seems to me that it is much better to automate the process.

3) It is not enough to compare destroot directories for proper header  
patches.
      mpfr is an example where the header files are the same on all  
architectures, but the the different architectures must still be built  
separately
            for everything to work correctly (see the Portfile comment).

I have no reason to think that 1 and 3 will happen with libart_lgpl,  
but making sure for each version, again, seems tedious.

I understand that the configure process was ugly for libart_lgpl (and  
a few other port).
Things would be greatly simplified if cross-compiling universal  
support were dropped (keeping only 32/64-bit universal).
I have advocated for this before but found my opinion to be in the  
minority.

Thanks,
Marcus

On Jun 11, 2009, at 2:56 PM, toby at macports.org wrote:

> Revision52182Authortoby at macports.orgDate2009-06-11 11:56:18 -0700  
> (Thu, 11 Jun 2009)Log Message
> Remove completely insane configure section, add simple patches to  
> accomplish the same goal.
> Remove darwin 6 section.
> Take maintainership to prevent anyone from getting bright ideas  
> about "fixing" the port again.
> Modified Paths
> 	• trunk/dports/graphics/libart_lgpl/Portfile
> Added Paths
> 	• trunk/dports/graphics/libart_lgpl/files/
> 	• trunk/dports/graphics/libart_lgpl/files/patch-Makefile.in
> 	• trunk/dports/graphics/libart_lgpl/files/patch-art_config.h
> Diff
> Modified: trunk/dports/graphics/libart_lgpl/Portfile (52181 => 52182)
>