On 12/6/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > On Wed, 06 Dec 2006 00:25:10 +0100, Hisham Muhammad <[EMAIL PROTECTED]> > wrote: > > > On 12/5/06, Jonas Karlsson <[EMAIL PROTECTED]> wrote: > >> On Tue, 05 Dec 2006 23:39:47 +0100, Hisham Muhammad > >> <[EMAIL PROTECTED]> > >> wrote: > >> > 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. > > > I still don't see the problem. The only problem I see with not symlinking > is that one has to update environmental variables so that the files > installed (and not symlinked) are found. If an app creates environmental > variables to resources outside of that dir, I can't see how that would > break things. Maybe I'm missing something.
I gave you an example already. Pkgconfig won't be able to find .pc files installed by subrecipes until they are symlinked. Ok, so then you could say "handle PKG_CONFIG_PATH too then". This breaks the earlier argument that "I can only see that there are six variables to take care of". Like I said, the set of variables is unbounded. Any app can come up with a scheme that requires an additional var to be handled, and then one would have to run after them as things break > >> Of cource shared messes things up, but one can choose only to symlink > >> that. And subdirs of lib, like in the pkgconfig case -- and soon we're back to where we started, with an added possibility of errors with perhaps little gain. > > 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. > > I still think that dependencies should be in every sub-recipe. And who is going to figure out the dependencies for each of the 200+ subrecipes? Most importantly, how? Removing Dependencies from subrecipes was André's idea, which I agreed with. He may be able to provide more insights on the rationale for this decision. > Look at my > other thread, where one of the components of Xorg 7.1 needed another > component of Xorg 7.1 (but the latter wasn't installed due to an error by > me). I would like to be able to update sub apps separatly, when it's > possible. Not running the whole compilation in order opens the gate for errors like the one you had. When going against the recommended and tested behavior of compiling a meta-recipe all at once, there's the option of emulating Compile's own behavior by using Compile -n -e -k on the subrecipe at your own risk. > The difference, the way I see it, is that dependencies fail once in a > while, but your idea of add do_symlink=no had the possibility to fail > 200+ -#_of_proto times. Which is why I only advocated it for proto's. (Of course, I proposed it as an alternative to tweaking env vars, not as an alternative to subrecipe dependencies). -- Hisham _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
