From: Steve Long <slong@rathaus.eclipse.co.uk>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Re: RFC: New build types
Date: Thu, 20 Mar 2008 06:51:13 +0000 [thread overview]
Message-ID: <frt12t$hhi$1@ger.gmane.org> (raw)
In-Reply-To: 47E1F263.3010508@gentoo.org
Rémi Cardona wrote:
> Steve Long a écrit :
>> First and foremost to give an environment wherein people can write their
>> installation scripts using the language they are most comfortable with.
>
> If bash is not "easy" or straightforward enough for what you are trying
> to achieve, then I'd say the package is broken (ie, hand-made configure
> script, odd makefiles and whatnot). Better fix the package rather than
> rewriting ebuilds, make the world a better place.
>
Heh, I'm fine with BASH believe it or not ;p nor do I have that much
interest in the other scripting languages. I really just think it would
make porting stuff to Gentoo a lot simpler for people who don't know Cbut
do know their language of choice.
>> Secondly efficiency; in the case of a pbuild it could be run from within
>> the PM; for something like a jbuild it would use the native tools and
>> existing libraries like ANT. For hbuild it would tie into Cabal. While
>> these may be used already, we go from PM -> BASH -> LangX. I'm just
>> saying give the _option_ to leave out the BASH bit when you have mature
>> tools in langX.
>
> Care to back that up with any sort of figure or number? Is bash really
> the bottleneck? For 90% of the tree's ebuilds, I would _gcc_ is the
> bottleneck. Then I'd bet a big lump on libtool. Not portage, not bash.
>
> But then again, I don't have any numbers to back that up either...
>
I don't have figures, but my understanding is that one of the major factors
in pkgcore's speed (which *is* impressive, even if the UI isn't quite there
yet) is that it doesn't reload bash for every phase. (The whole
ebuild "daemon" or ebd thing.)
> Honestly, maybe it could be a fun project, but I'm hardly convinced it
> would bring any sort of real advantage to the tree. In fact, having
> ebuilds in many languages would probably wreak havoc more than anything
> else.
>
I don't see how it would wreak more havoc than a novice using, eg ANT from
Java which s/he is comfortable with, and then further having to learn BASH
peculiarities when things don't fit with the eclass. But yeah, the fun is
what attracts me to the idea more than anything.
It's something I'd imagine would be used only for packages developed in the
relevant overlay, since that's where the people who know the language
develop stuff (and they'd be the ones maintaining their version.) However,
they'd need to know that, once they've signed off on it, the central tree
will support it without further code changes.
--
gentoo-dev@lists.gentoo.org mailing list
next prev parent reply other threads:[~2008-03-20 6:44 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-18 10:18 [gentoo-dev] RFC: New build types Steve Long
2008-03-18 10:11 ` Rémi Cardona
2008-03-20 3:59 ` [gentoo-dev] " Steve Long
2008-03-20 5:13 ` Rémi Cardona
2008-03-20 6:51 ` Steve Long [this message]
2008-03-20 7:15 ` [gentoo-dev] " Brian Harring
2008-03-21 12:52 ` [gentoo-dev] " Steve Long
2008-03-20 10:44 ` [gentoo-dev] " Petteri Räty
2008-03-21 12:01 ` [gentoo-dev] " Steve Long
2008-03-20 5:31 ` [gentoo-dev] " Marius Mauch
2008-03-18 10:32 ` [gentoo-dev] " Jakub Moc
2008-03-18 21:23 ` Luca Barbato
2008-03-20 4:02 ` [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='frt12t$hhi$1@ger.gmane.org' \
--to=slong@rathaus.eclipse.co.uk \
--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