On Wed, 06 Dec 2006 23:38:57 +0100, Hisham Muhammad <[EMAIL PROTECTED]> wrote:
> 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 > Ok, you've convinced me :) > >> > 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. > There are not that many dependencies. The complete meta recipe Xorg has 9 dependencies. If you look at the separate sub packages, i.e. Xorg Libs, they have about 3 depenndecies each. Of cource they depend on earlier parts of the Xorg meta, but we can't check on that atm, as we don't know what's installed in the meta directory. >> 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. > Perhaps I used the wrong example, as my point didn't get through. What I meant was that if dependencies was listed in the sub recipes I would have got a warning that the dependency wasn't installed (but again that require that we know what's installed in the meta directory). As for 'Compile --app-name --app-version -keep', I think that the sub recipes should emulate this by specifying 'part_of_name=Xorg' and 'part_of_version=7.1' inside the recipe (the variable names could be discussed). >> 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). > It did not sound like you meant proto only, but more as in "start with proto and then experiment with the rest", but I guess we misunderstood eachother again :) Anyway I feel like we should approach this some other way as I'm stuck on that we don't know what files are installed in the meta directory. -- /Jonas Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
