Re: apt-0.5.4-1061 build failure

> Am 22.04.2014 um 21:12 schrieb Alexander Hansen <[email protected]>:
> 
>> On 4/22/14, 11:39 AM, Max Horn wrote:
>> Hi again,
>> 
>>> On 22.04.2014, at 20:19, Alexander Hansen <[email protected]> wrote:
>>> 
>>> On 4/22/14, 10:47 AM, Max Horn wrote:
>> 
>> [...]
>> 
>>> 
>>> Ah, that explains it.  I didn't appreciate that the logic in PkgVersion.pm only gets triggered on each build _operation_ rather than each individual package build.
>> 
>> Totally understandable. The code there is quite complex and sometimes even, uhm, let's say "a bit eccentric" ;-).
>> 
>> There are various things about it that bother me. E.g. the names of the path-prefix scripts seem to follow no particular rhyme and reason:
>> - path-prefix-10.6
>> - path-prefix-g++-3.3
>> - path-prefix-g++-4.0
>> - path-prefix-clang
>> - path-prefix-libcxx
>> 
>> BTW, the preinst script only removes the clang and libcxx variants, it seems, not the others. On purpose?
> 
> Yes.  They're the only ones which are actually in the PATH on 10.8 and 10.9, so they're the only ones that need -Wno-error=unused-command-line-argument-hard-error-in-future added.
> 
>> On the other hand, the install.sh script in the fink.git repository deals with the first three of these, but not the latter. Again, I wonder: Is this intentional?
>> 
>> This is also why /sw/var/lib/fink/path-prefix-10.6/ etc. is part of the .deb (as you point out below), but the -clang and -libcxx variants are not.
>> 
>>> 
>>> I assumed (without having time to delve through the history) that we deliberately didn't want to regenerate the wrappers for every build operation because of potential fragility.  I wondered why the wrappers weren't encoded in the .deb, myself, since that would be even less fragile, but at the time it seemed like that change needed a bit more brainpower than I had available, and we were being swamped with "foo doesn't build with xcode-5.1" reports.
>> 
>> Again: Understandable, so I indeed wonder the same... I wonder if anybody can think of a reason to not put the wrappers in the .deb?
>> 
>> The only thing that comes to my mind here is that putting stuff in %p/var into a .deb seems wrong, but (a) we already do that for the other wrappers, and (b) it would be easy enough to change the location of those files (but doing that would be somewhat dangerous, as it could break already running builds).
>> 
>>> 
>>> I personally feel that having the proper compiler wrapper setup in the .deb makes more sense than generating them dynamically--apart from fixing damaged setups, of course.  Right now on 10.7+ fink installs:
>>> 
>>> /sw/var/lib/fink/path-prefix-10.6/compiler_wrapper
>>> /sw/var/lib/fink/path-prefix-g++-3.3/g++
>>> /sw/var/lib/fink/path-prefix-g++-4.0/g++
>>> /sw/var/lib/fink/path-prefix-10.6/c++
>>> /sw/var/lib/fink/path-prefix-10.6/c++-4.0
>>> /sw/var/lib/fink/path-prefix-10.6/c++-4.2
>>> /sw/var/lib/fink/path-prefix-10.6/cc
>>> /sw/var/lib/fink/path-prefix-10.6/clang
>>> /sw/var/lib/fink/path-prefix-10.6/clang++
>>> /sw/var/lib/fink/path-prefix-10.6/g++
>>> /sw/var/lib/fink/path-prefix-10.6/g++-4.0
>>> /sw/var/lib/fink/path-prefix-10.6/g++-4.2
>>> /sw/var/lib/fink/path-prefix-10.6/gcc
>>> /sw/var/lib/fink/path-prefix-10.6/gcc-4.0
>>> /sw/var/lib/fink/path-prefix-10.6/gcc-4.2
>>> /sw/var/lib/fink/path-prefix-g++-3.3/c++
>>> /sw/var/lib/fink/path-prefix-g++-4.0/c++
>>> 
>>> and none of these are actually used, but relies on FinkVersion.pm to install the wrappers that do get used.
>> 
>> Yup. So, unless somebody can think of a good reason for this: Let's change it. ONe way to do this:
>> 
>> 1) Instead, use the content of ensure_libcxx_prefix and ensure_clang_prefix to create new files
>>   compiler_wrapper-clang.in
>>   compiler_wrapper-libcxx.in
>> 
>> 2) Modify install.sh to install these path-prefix wrappers in the correct places.
>> 
>> 3) Modify ensure_libcxx_prefix and ensure_clang_prefix to only return the path, not do anything else.
>> 
>> 4) While at it, we can probably do the same with ensure_gpp_prefix and ensure_gpp106_prefix.
>> In fact, we can get rid of these four functions, as they now only return strings...
>> 
>> 
>> Cheers,
>> Max
> 
> My thought for #1 was a bit simpler:  just have the three compiler-wrapper*.in files sitting around in the source and not generate them dynamically at all.

That actually sounds exactly like what I meant with my point #1 :)

>  I can't think of a compelling reason to do so if they get written into the .deb, since a "fink reinstall fink" should restore them if something happens.
> 
> On the other hand, if folks think that having files that go into %p/var in a .deb is a no-no, then ensure_gpp106_prefix already has the ability to create the wrapper and symlinks dynamically.

Which is somewhat weird, though, as those symlinks are also created by install.sh and are in the .deb, it seems. I really wonder why that work is done twice - what am I missing?

Cheers,
Max

> 
> I'd advocate consistency here. :-)
> -- 
> Alexander Hansen, Ph.D.
> Fink User Liaison
> My package updates: http://finkakh.wordpress.com/
> 

------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
fink-core mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core