On Fri, Dec 09, 2011 at 06:15:58PM +0000, Hin-Tak Leung wrote: > --- On Fri, 9/12/11, Theppitak <t...@linux.thai.net> wrote: > > > This case is common. Just set PKG_CONFIG_PATH and > > LD_LIBRARY_PATH > > environments to your home-based dir. > > That does not do. How many piece of demo/still-in-dev software I (or > somebody else) want to *try*, which needs those?
It's up to you. Just choose the way that's suitable for you. > > I think you could think about how many dependent software libdatrie has, > and whether it make sense to bundle it in the swath release source tarball. > (you can keep the development separate). > > R does that whenever it goes into release (it bundles a few 3rd party > general libraries like libjpeg and pcre, as well as some R-specific ones > which have separate dev repositories). Oh, no. It's not fun at all to release my own code twice (or more). And the practice just promotes more forking than sharing. > > I also considered this, but libdatrie has had its own uses > > in many > > applications. Not just for non-Thai dictionaries, > > it's known to have > > been used in information retrieval projects, or even > > bio-informatics. > > Benefit of splitting it outweighs the cost of bundling it > > in every > > piece of such software. And in your particular case > > of casual tryout, > > common technique is well-known. > > I doubt that. libdatrie is not known at all from any of redhat/fedora's > 3rd party repositories. In fact it was difficult to find by googling. Just like what you said on Debian, RedHat/Fedora cannot represent the world. I've been contacted via personal e-mails for bug reports and patches from around the world. (Probably, it gets known through Wikipedia [1].) The reporters let me know how they use it in their projects, which may not be packaged or even released. Its LGPL license allows them to use it in any non-free projects (as long as it's not bundled). [1] http://en.wikipedia.org/wiki/Trie > > Yep, I agree it's very complicated, compared to this: > > > > Suppose you want to install locally under > > ${HOME}/local. Then, in your > > ~/.bashrc: > > > > export PKG_CONFIG_PATH=${HOME}/local/lib/pkgconfig > > export LD_LIBRARY_PATH=${HOME}/local/lib > > export PATH=${HOME}/local/bin:${PATH} > > How far you do before you start to have a shadow / under your home? > That's for one small command-line utility swath. Hmm.. It seems I should not simplify things with you. If you like to try things out by compiling them yourself, using ~/.bashrc is a simple provision for long-term use. But if the only software you want to compile in your lifetime is swath, then use your smart method, not this foolproof one. > > Not satisfied after trying? "make uninstall" is > > available to help. > > That depends on two things: > > - the original partly used src/ is still available . That shall not be > the case if say, I am trying it out briefly, (meanwhile, I might want > to tidy up), then a few months later decided it is not for me. So, you mean "rm -rf swath-<version>" was missing in my steps? > - if it is to clear-up after a messed-up TEXMF or /usr/local, the last > thing one wants is to run another automated script to hope to clean up > a mess. Why not? What kind of "messed-up" do you mean? > > No, I didn't, as demonstrated above. I think the > > technique is very > > common. > > common, where? It's basically how GARNOME and JHBuild work, for example. > > As I said, the home installation technique is very > > common. It would > > have made it too tedious to read to list all well-known use > > cases in > > the first place. > > I see why it doesn't get into TeXLive... > > You are not making it easy for *potential* user to try it out without > installing, and that's just a tiny command-line tool. You just tried to make it look harder with your personal conditions. Yes, I can elaborate things for you, but that would unnecessarily make it long and hard to read, as you want it to be. -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ _______________________________________________ Cjk maillist - Cjk@ffii.org https://lists.ffii.org/mailman/listinfo/cjk
