On 12/5/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > On Tue, 05 Dec 2006 23:39:47 +0100, Hisham Muhammad <[EMAIL PROTECTED]> > wrote: > > > On 12/5/06, André Detsch <[EMAIL PROTECTED]> wrote: > >> On 12/5/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > >> > I'm just trying to build Xorg 7.1 and one thing that strikes me is > >> that I > >> > think that Compile spend more time at symlinking (and running > >> ldconfig) > >> > after each sub app has compiled then actully compiling the apps. > >> Wouldn't > >> > it be possible to set PATH and LD_LIBRARY_PATH to include the actual > >> > directory, /Programs/Foo/1.2/bin and /Programs/Foo/1.2/lib > >> respectively, > >> > during the compilation of a meta recipe, instead of running > >> symlinkprogram > >> > each time? > >> > >> Sounds a good idea. Can you implement this and test with the Xorg > >> recipe? Please ensure the changes do not affect regular (non-meta) > >> recipes. > > > > Won't work. PATH and LD_LIBRARY_PATH won't be enough. The proto stuff > > installs headers. Then you'll have to handle C_INCLUDE_PATH. And if > > something uses C++, then CPLUS_INCLUDE_PATH and so on and so on and so > > on. It's hackish. And then some other recipe in the future may look > > for share/ stuff which won't work unless properly symlinked. Doing > > this is asking for meta-recipes to break in mysterious ways. > > > "and so on and so on and so on." > I can only see that there are six variables to take care of (PATH, > MANPATH, INFOPATH, LD_LIBRARY_PATH, C_INCLUDE_PATH and CPLUS_INCLUDE_PATH) > of which two have to have two entries bin/sbin and lib/libexec.
No, the set of variables is unbounded: think of PkgConfig, Python, etc. Potentially, any program can create an environment variable that establishes a path dependency that can be necessary in a later step. > Of cource shared messes things up, but one can choose only to symlink that. > > > Instead, add a new flag "do_symlink=no" and set that on sub-recipes > > that you can test and ensure that they don't need to be symlinked in > > an intermediate step. This is the safest approach and will result in > > the desired speedups. For example, you can skip symlinking on all > > proto's and only symlink in the last one, so that when libs are > > compiled, the proto headers are linked (yes, this depends on a proper > > order for includes in the main recipe, but order is already relevant). > > > You're funny. :) > You want me to go through 200+ recipes one by one and see which don't need > symlinking and which needs it? Perhaps if I got paid ;) No, I don't. Sorry if I phrased it badly -- I should have said "the best approach would be for one to set that on sub-recipes (etc.)". I didn't mean to say "go and do it", I meant to say "if one were to do it, this is how I think it's the right way to be done". In another email, you suggested for sub-recipes to have 200+ hand-maintained Dependencies files, while we removed Dependencies files from sub-recipes precisely because of the maintenance burden. That's the difference between a "wouldn't it be nice if" idea and something that can be managed in practical terms. Working on the Xorg recipe set is a huge amount of work and I'm well aware of that -- I hold memories of writing custom scripts that read the HTML from x.org's directory listings and created the original recipes. André has also put a lot of work on them. Speeding up the compilation, while not essential, would be a nice addition, but any tweak made to those recipes really is a lot of work. The do_symlink=no feature I suggested could be used even if it was not applied to the maximal valid set of subrecipes (using it in protos alone could be a noticeable speed-up). But like I said, it's a non-essential optimization (and the variable-tweaking approach, on the other hand, is error-prone). Your general observation that some of the symlinking can be skipped, though, remains a valid one. -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
