1 |
On Sat, Feb 23, 2008 at 10:45 PM, Alec Warner <antarus@g.o> wrote: |
2 |
> On 2/20/08, Felipe Contreras <felipe.contreras@×××××.com> wrote: |
3 |
> > b) Error are difficult to handle since bash doesn't have exceptions |
4 |
> |
5 |
> I disagree here: most errors are fatal anyway any non fatal errors can |
6 |
> be printed and saved via the elog facility. |
7 |
|
8 |
Yes, for the most common usage that's true, but that think about this |
9 |
example: I'm compiling gstreamer-plugins-good, which needs libraw1394, |
10 |
but the compilation fails, perhaps that user is not interested in that |
11 |
particular plugin so a dialog can pop up and the user can choose if to |
12 |
continue without the libraw stuff or fail. |
13 |
|
14 |
I'm sure that can be done without exceptions but as the complexity |
15 |
increases properly checking/passing around error values/messages |
16 |
becomes tedious. |
17 |
|
18 |
> > c) Persistent information is difficult to achieve (no database stuff) |
19 |
> |
20 |
> How is this a bash limitation? Most languages don't have 'database |
21 |
> stuff' built in. |
22 |
> I don't see how saving stuff to files is much different than the env |
23 |
> dumping we do in bash? |
24 |
|
25 |
I guess it's mostly the burden of serializing/parsing all that stuff. |
26 |
|
27 |
> > A more featured language could allow for example: filtered output, |
28 |
> > exception handling->state storage->resuming. |
29 |
> > |
30 |
> > But the big deal is with the package definition, recently I learned |
31 |
> > about Domain Specific Languages, and I think that is the best option. |
32 |
> > |
33 |
> > A new dsl allows many interesting features in the package definition |
34 |
> > itself like: inheritance, exceptions, arrays, hash tables, objects, |
35 |
> > modules, documentation, information messages, etc. |
36 |
> |
37 |
> Note that most languages allow for the same things...so why would we |
38 |
> author our own language? What runtime would it use? |
39 |
|
40 |
The language can be something very simple that has bash embedded. That |
41 |
has the advantage that you can just copy paste what you are doing |
42 |
already. |
43 |
|
44 |
As more ideas appear the DSL can be updated, but still, the embedded |
45 |
bash would always be there. |
46 |
|
47 |
<snip/> |
48 |
> > This is based on an already working prototype made in Ruby, so it's |
49 |
> > biased towards Ruby facilities. |
50 |
> |
51 |
> It looks Rakish ;) |
52 |
|
53 |
Perhaps, the only interesting thing here is that those commands are |
54 |
not defined internally. There's an auxiliary bash shell that is |
55 |
running those commands. Not like "system" calls, which loose the |
56 |
environment between calls, this is something that cooperates nicely. |
57 |
|
58 |
> > I've tried different build systems: rpm, dpkg, autopackage. |
59 |
> > Unfortunately I never tried ebuild because it was based on bash as far |
60 |
> > as I could tell. |
61 |
> |
62 |
> Typically a 'build system' would refer to 'autotools' or 'ant' or |
63 |
> 'setuptools' not an ebuild. |
64 |
|
65 |
Is there such a big difference? |
66 |
|
67 |
I'm sure it's possible to by-pass autotools and write down all the |
68 |
commands required to build something in an ebuild. Similarly it's |
69 |
possible to use autotools to compile and install a bunch of packages. |
70 |
|
71 |
Those "build systems" also need to be updated, but that's another story. |
72 |
|
73 |
> > After almost a decade of using Linux I still haven't found a build |
74 |
> > system that suits all my needs. AFAIK ebuild is the most advanced but |
75 |
> > it's still relying on ancient technology (bash scripts) so there will |
76 |
> > always be limitations despite the brilliant ideas. |
77 |
> |
78 |
> Bash is not 'ancient' and it works suprisingly well for the vast |
79 |
> majority of cases. I realize using a high level language would |
80 |
> probably make some tasks easier (mmm dicts and real arrays). There is |
81 |
> the matter of porting over 10000 ebuilds however ;) |
82 |
|
83 |
Yeah, bash is pretty good for many things, just doesn't scale that much. |
84 |
|
85 |
At some point someone decided the current status was not good enough |
86 |
and decided to create ebuild, even though he was well aware that |
87 |
thousands of already existing instructions about how to build packages |
88 |
would have to be re-written. |
89 |
|
90 |
If it's easy to write people will possibly even write more of those. |
91 |
Take for example ArchLinux which also has around 10,000 packages |
92 |
simply because it's so easy to write them. |
93 |
|
94 |
And with something that is distribution agnostic, different |
95 |
communities can benefit from sharing the same rules. |
96 |
|
97 |
> > |
98 |
> > The core of a distribution is the "packaging" system, and the core of |
99 |
> > the packaging system is the building system, which has no reason not |
100 |
> > to be distribution agnostic, and actually, packaging system agnostic. |
101 |
> > |
102 |
> > Why not create a new build system with a state of the art programming |
103 |
> > language, and an advanced DSL that actually other distributions could |
104 |
> > use? |
105 |
> |
106 |
> I would talk to Drobbins, he was talking about something like this to |
107 |
> manage complexity. |
108 |
|
109 |
Will do. |
110 |
|
111 |
Best regards. |
112 |
|
113 |
-- |
114 |
Felipe Contreras |
115 |
-- |
116 |
gentoo-dev@l.g.o mailing list |