From: "Alec Warner" <antarus@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] The future of ebuild
Date: Sat, 23 Feb 2008 12:46:00 -0800 [thread overview]
Message-ID: <b41005390802231246y21012557o87c88e9ce69fadf4@mail.gmail.com> (raw)
In-Reply-To: <b41005390802231245o579c7d41i2a53b7d0c7c285@mail.gmail.com>
On 2/23/08, Alec Warner <antarus@gentoo.org> wrote:
> On 2/20/08, Felipe Contreras <felipe.contreras@gmail.com> wrote:
> > Hi gentooists,
> >
> > I've been reading news sites about some changes happening in Gentoo
> > and I thought it might be a good time to submit some ideas I've been
> > baking for several years.
> >
> > I come from a Linux From Scratch background, I like the feeling of
> > knowing every single corner of my system and the fact that there isn't
> > anything that I don't want or need. However, typing every single
> > command by hand is far from ideal, so at first I started writing some
> > scripts and eventually I wrote a build system that suited my needs. I
> > did it in bash for several reasons.
> >
> > After a while I realized bash wasn't exactly the best language to
> > write such thing. Mainly because:
> >
> > a) The code ends up with a lot of stuff for handling strings properly
> > (like escaping sequences)
>
>
> Yes this is annoying
>
>
> > b) Error are difficult to handle since bash doesn't have exceptions
>
>
> I disagree here: most errors are fatal anyway any non fatal errors can
> be printed and saved via the elog facility.
>
>
> > c) Persistent information is difficult to achieve (no database stuff)
>
>
> How is this a bash limitation? Most languages don't have 'database
> stuff' built in.
> I don't see how saving stuff to files is much different than the env
> dumping we do in bash?
Er, I meant saving stuff to databases ;)
>
>
> > d) Package information is difficult to fetch/store (no objects/struct)
>
>
> Yes.
>
>
> >
> > A more featured language could allow for example: filtered output,
> > exception handling->state storage->resuming.
> >
> > But the big deal is with the package definition, recently I learned
> > about Domain Specific Languages, and I think that is the best option.
> >
> > A new dsl allows many interesting features in the package definition
> > itself like: inheritance, exceptions, arrays, hash tables, objects,
> > modules, documentation, information messages, etc.
>
>
> Note that most languages allow for the same things...so why would we
> author our own language? What runtime would it use?
>
>
> >
> > Take this example:
> >
> > package Binutils < Gnu
> > definition
> > @version = "2.17"
> > @name = "binutils"
> > super() # run the Gnu definition stuff
> >
> > @config_opts = "--disable-nls --with-sysroot=\"#{$sys_root}\"
> > --enable-shared --disable-multilib"
> > end
> >
> > steps
> > build
> > cd #{$top_build_dir}
> > mkdir -p #{@build_dir}
> > cd #{@build_dir}
> > :configure "script" => "../#{@dir}/configure", "opts" => @config_opts
> > make configure-host
> > make
> > end
> >
> > install
> > cd #{$top_build_dir}
> > cd #{@build_dir}
> > make install
> > end
> > end
> > end
> >
> > This is based on an already working prototype made in Ruby, so it's
> > biased towards Ruby facilities.
>
>
> It looks Rakish ;)
>
>
> >
> > I've tried different build systems: rpm, dpkg, autopackage.
> > Unfortunately I never tried ebuild because it was based on bash as far
> > as I could tell.
>
>
> Typically a 'build system' would refer to 'autotools' or 'ant' or
> 'setuptools' not an ebuild.
>
>
> >
> > After almost a decade of using Linux I still haven't found a build
> > system that suits all my needs. AFAIK ebuild is the most advanced but
> > it's still relying on ancient technology (bash scripts) so there will
> > always be limitations despite the brilliant ideas.
>
>
> Bash is not 'ancient' and it works suprisingly well for the vast
> majority of cases. I realize using a high level language would
> probably make some tasks easier (mmm dicts and real arrays). There is
> the matter of porting over 10000 ebuilds however ;)
>
>
> >
> > The core of a distribution is the "packaging" system, and the core of
> > the packaging system is the building system, which has no reason not
> > to be distribution agnostic, and actually, packaging system agnostic.
> >
> > Why not create a new build system with a state of the art programming
> > language, and an advanced DSL that actually other distributions could
> > use?
>
>
> I would talk to Drobbins, he was talking about something like this to
> manage complexity.
>
>
> >
> > I would like to hear your opinions on this matter.
> >
> > --
> > Felipe Contreras
> >
> > --
> > gentoo-dev@lists.gentoo.org mailing list
> >
> >
>
--
gentoo-dev@lists.gentoo.org mailing list
next prev parent reply other threads:[~2008-02-23 20:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-20 20:40 [gentoo-dev] The future of ebuild Felipe Contreras
2008-02-21 12:29 ` Duncan Coutts
2008-02-24 11:02 ` Felipe Contreras
2008-02-24 19:43 ` Santiago M. Mola
2008-02-25 10:59 ` Jakub Moc
2008-02-25 11:24 ` Sebastian Volke
2008-02-24 19:49 ` Duncan Coutts
2008-02-23 20:45 ` Alec Warner
2008-02-23 20:46 ` Alec Warner [this message]
2008-02-24 11:53 ` Felipe Contreras
2008-02-24 18:50 ` Luis Francisco Araujo
2008-02-24 23:32 ` Alec Warner
2008-02-25 6:43 ` [gentoo-dev] " Steve Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b41005390802231246y21012557o87c88e9ce69fadf4@mail.gmail.com \
--to=antarus@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox