On Friday, December 31, 2010 11:16:41 Enrico Weigelt wrote:
> * Mike Frysinger <vapier@gentoo.org> schrieb:
> > On Thursday, December 30, 2010 01:46:34 Enrico Weigelt wrote:
> > > Little example, where I'm working on right now: coreutils and gnulib.
> > > Imagine, these jerks not just collected hundreds of (sometimes really
> > > broken) tests and workarounds instead of fixing the source - they
> > > also collected them in another "package" called gnulib, which gets
> > > fetched via git (from the current head instead of some release tag!)
> > > and _copied_ into the coreutils source tree by some obscure
> > > "bootstrap" script. Wow, self-modifying code. Violating all rules
> > > of the very first semester in software engineering ;-o
> >
> > yeah, once you start fixing Microsoft's runtime library and Solaris' C
> > library and old UNIX systems whose owners long died and ........, feel
> > free to get gnulib obsoleted. but until that happens, stop living in an
> > unrealistic world. gnulib exists for a very real reason and is
> > extremely useful to many many people.
>
> You didn't get my point. I was talking about the way of copying
> in (parts of) gnulib into other package's source tree in an
> unpredicable way, directly within the build process.
i'm guessing you've never actually used gnulib and thus know little about how
it works. importation of it isnt "unpredictable" at all. the developer doing
the import closely controls what functions exactly they wish to import.
> The clean way (tm) would be making it a real library
again, clearly you dont follow anything about gnulib. they're already working
on an actual shared library now called libposix.
> I'm currently in the process of doing exactly that.
i'm sure that will totally see real use and isnt a complete waste of time
-mike
01-02-2011, 08:43 PM
Enrico Weigelt
Is a compilation depend on the running kernel?
* Mike Frysinger <vapier@gentoo.org> schrieb:
> > You didn't get my point. I was talking about the way of copying
> > in (parts of) gnulib into other package's source tree in an
> > unpredicable way, directly within the build process.
>
> i'm guessing you've never actually used gnulib
Actually, I do, while making coreutils (the git tree, not tarballs)
cleanly crosscompile'able in sysroot.
> importation of it isnt "unpredictable" at all. the developer doing
> the import closely controls what functions exactly they wish to import.
The unpredictable point the the imported version. If it does
an git fetch, you dont know what you're actually getting in.
Building the same coreutils version twice (with some delay in
between) is likely to actually run on _different_ trees.
Now I curious how some wants to do proper QM on that ;-o
> > The clean way (tm) would be making it a real library
>
> again, clearly you dont follow anything about gnulib. they're
> already working on an actual shared library now called libposix.
Fine. Let's see when it really replaced gnulib. Guess takes a while,
but I needed a solution right now.
> > I'm currently in the process of doing exactly that.
>
> i'm sure that will totally see real use and isnt a complete waste of time
actually, real use will be in certain medical embedded devices
used all around the world ...
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
On Sunday, January 02, 2011 16:43:14 Enrico Weigelt wrote:
> * Mike Frysinger <vapier@gentoo.org> schrieb:
> > > You didn't get my point. I was talking about the way of copying
> > > in (parts of) gnulib into other package's source tree in an
> > > unpredicable way, directly within the build process.
> >
> > i'm guessing you've never actually used gnulib
>
> Actually, I do, while making coreutils (the git tree, not tarballs)
> cleanly crosscompile'able in sysroot.
that doesnt mean you've used gnulib. that means you compiled a project which
uses it.
> > > I'm currently in the process of doing exactly that.
> >
> > i'm sure that will totally see real use and isnt a complete waste of time
>
> actually, real use will be in certain medical embedded devices
> used all around the world ...
what devices exactly so i know which to avoid
-mike
Is a compilation depend on the running kernel?
