public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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



  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