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
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