> Am 22.04.2014 um 21:12 schrieb Alexander Hansen <alexanderk.han...@gmail.com>: > >> 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.
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 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
