From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JT1G9-0007kG-0S for garchives@archives.gentoo.org; Sat, 23 Feb 2008 20:46:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 73CA4E044E; Sat, 23 Feb 2008 20:46:02 +0000 (UTC) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by pigeon.gentoo.org (Postfix) with ESMTP id 11562E044E for ; Sat, 23 Feb 2008 20:46:01 +0000 (UTC) Received: by fk-out-0910.google.com with SMTP id 18so1931209fkq.2 for ; Sat, 23 Feb 2008 12:46:01 -0800 (PST) Received: by 10.82.161.19 with SMTP id j19mr1577531bue.0.1203799560916; Sat, 23 Feb 2008 12:46:00 -0800 (PST) Received: by 10.78.46.19 with HTTP; Sat, 23 Feb 2008 12:46:00 -0800 (PST) Message-ID: Date: Sat, 23 Feb 2008 12:46:00 -0800 From: "Alec Warner" Sender: antarus@scriptkitty.com To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] The future of ebuild In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <94a0d4530802201240v19dde77vff199cb11ece0bbd@mail.gmail.com> X-Google-Sender-Auth: 66a459a0088ffa15 X-Archives-Salt: 650dbd67-7205-4df1-ab27-8893e03a7048 X-Archives-Hash: 53849f4589569575600e5c354c66f5ba On 2/23/08, Alec Warner wrote: > On 2/20/08, Felipe Contreras 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