Hi again,

On 22.04.2014, at 20:19, Alexander Hansen <alexanderk.han...@gmail.com> 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?

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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

------------------------------------------------------------------------------
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
fink-core@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core

Reply via email to