Gentoo Archives: gentoo-user

From: Michael Mol <mikemol@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Can't emerge gnash
Date: Thu, 12 Jul 2012 20:48:48
Message-Id: CA+czFiCu+hgN3-a9_8avToZRkiOk03E0VqSiVFvrZju_NKy0sQ@mail.gmail.com
In Reply to: Re: [gentoo-user] Can't emerge gnash by Ezequiel Garcia
1 On Thu, Jul 12, 2012 at 4:37 PM, Ezequiel Garcia <elezegarcia@×××××.com> wrote:
2 > On Thu, Jul 12, 2012 at 5:14 PM, Michael Mol <mikemol@×××××.com> wrote:
3 >
4 >>
5 >> Developer here, too. Mostly C++ on Windows, though I far prefer the
6 >> way Linux does things. :)
7 >>
8 >> In theory, using in-house code seems like a great thing. Having
9 >> written it, I understand it, I understand its API, and it's not a big
10 >> blob of unknowns for me to fear when debugging my programs.
11 >>
12 >> In practice, I've seen more time (and money!) spent reinventing the
13 >> wheel for any given project than it would take to pull in a library.
14 >> I've seen and participated, designed and/or led in the redevelopment
15 >> of locking mechanisms, nested image compositing engines, database
16 >> abstraction layers, deferred I/O abstraction frameworks and probably a
17 >> half-dozen other things I'm forgetting right now.
18 >>
19 >> Each and _every_ time, a great deal amount of developer time is
20 >> consumed at the outset with development, and then over the life of the
21 >> code as bugs (some of which simply come from underestimating or
22 >> misunderstanding the resulting complexity of the system) turn up.
23 >>
24 >> NIH costs. I'd rather use a widespread library than write my own,
25 >> wherever possible.
26 >>
27 >> But, of course, that's just _my_ humble opinion. And each circumstance
28 >> warrants its own cost/benefit analysis.
29 >>
30 >
31 > This is off-topic now :-( But it's a nice discussion :-)
32 >
33 > I agree with you mostly. I think you're a bit biased against
34 > rolling-your-own, perhaps
35 > because working on windows enforces that -there are less open
36 > libraries/programs you can reuse-.
37 >
38 > Again, it's a great thing to re-use and it's evil to reinvent the wheel.
39 > It has all sorts of advantages, we all know that.
40 >
41 > On the other hand, as you say, each circumstance needs its own analysis.
42 >
43 > Let me use an example: I'm writing a middle-size application in C++ that
44 > will run on an embedded device, linux only.
45 > Let's say I need some threads and some mutexes.
46 > Heck, I'm not going to use boost if I can just wrap pthreads around
47 > some lightweight classes.
48
49 In that circumstance, you're mostly going to be distributing firmware
50 blobs. I'd probably rip the relevant code out of boost (perhaps set up
51 a script to do this), drop it somewhere in my project folders, and tie
52 it in with my build system. Respecting, of course, the license
53 requirements of boost.
54
55 It's unfortunate that boost's build system isn't modular, and
56 especially that it won't parallelize. I'll probably look at it at some
57 point to figure out if I know enough to rewrite it in autotools. I
58 could totally see a "--with-this-module=yes" per-module, as opposed to
59 an "--enable-all" for those users who don't know which parts they do
60 or don't need.
61
62 It's something that needs to be done. The question is who's going to
63 have the time and inclination.
64
65 --
66 :wq