On 4/22/14, 11:39 AM, Max Horn wrote: > 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? >
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. 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. 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 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
