Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
>
> Thanks. But I think we can simplify that for now, since lua53 isn't
> available (neither in the official tree or the lua overlay) and
>
> >=lua-5.2 is hardmasked.
Anyway, I think, we need "my default patch for luajit support" here (which,
actually, I'd suggest to apply on all packages in the tree, that declares Lua
support. Should I start thread about it here?):
iuse+=luajit
deps~= luajit? (dev-lang/luajit:2) !luajit? ( dev-lang/lua )
or
src_configure/install {
local lua=lua
use luajit && lua=luajit
INST_PATH_LMOD=$($(tc-getPKG_CONFIG) --variable INSTALL_LMOD ${lua})"
# and/or INST_PATH_CMOD=$($(tc-getPKG_CONFIG) --variable INSTALL_CMOD ${lua})"
}
instead of "default" hard-dep on puc-rio lua... ;)
--
Best regards,
mva
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 23 February 2015 at 14:17, Vadim A. Misbakh-Soloviov wrote:
> I'd also say:
>
> neovim:
>
>> CDEPEND="dev-lang/luajit
>> <...>
>> dev-lua/LuaBitOp
>
> 1) I'm not sure luajit:1 fits the dep
> 2) LuaJIT:2 has it's own bit modules and is unneded LuaBitOp
Thanks! I don't know that much about lua, so this is very helpful.
> Unibilium:
> 1.1.2 made a day ago. Bump, please ;)
Already on it.
> lua-MessagePack:
>> RDEPEND=">=dev-lang/lua-5.1"
> And what about LuaJIT? Huh?
Yeah, but I just followed what I found upstream.
> Also, I've it in lua overlay, called dev-lua/messagepack, though. Naming can
> be discussed.
I don't mind either way. But again, I just followed upstream.
> But main point is:
>
>> RDEPEND="
>>!luajit? (
>>!lua53? (
>>|| (
>>=dev-lang/lua-5.1*
>>=dev-lang/lua-5.2*
>>)
>>)
>>lua53? ( =dev-lang/lua-5.3* )
>>)
>>luajit? ( dev-lang/luajit:2 )
>>"
>> <...>
>>src_install() {
>>local lua=lua
>>use luajit && lua=luajit
>>
>>insinto "$($(tc-getPKG_CONFIG) --variable INSTALL_LMOD ${lua})"
>>if use lua53; then
>>doins src5.3/MessagePack.lua
>>else
>>doins src/MessagePack.lua
>>fi
>>}
Thanks. But I think we can simplify that for now, since lua53 isn't
available (neither in the official tree or the lua overlay) and
>=lua-5.2 is hardmasked.
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
I'd also say:
neovim:
> CDEPEND="dev-lang/luajit
> <...>
> dev-lua/LuaBitOp
1) I'm not sure luajit:1 fits the dep
2) LuaJIT:2 has it's own bit modules and is unneded LuaBitOp
Unibilium:
1.1.2 made a day ago. Bump, please ;)
lua-MessagePack:
> RDEPEND=">=dev-lang/lua-5.1"
And what about LuaJIT? Huh?
Also, I've it in lua overlay, called dev-lua/messagepack, though. Naming can
be discussed. But main point is:
> RDEPEND="
>!luajit? (
>!lua53? (
>|| (
>=dev-lang/lua-5.1*
>=dev-lang/lua-5.2*
>)
>)
>lua53? ( =dev-lang/lua-5.3* )
>)
>luajit? ( dev-lang/luajit:2 )
>"
> <...>
>src_install() {
>local lua=lua
>use luajit && lua=luajit
>
>insinto "$($(tc-getPKG_CONFIG) --variable INSTALL_LMOD ${lua})"
>if use lua53; then
>doins src5.3/MessagePack.lua
>else
>doins src/MessagePack.lua
>fi
>}
(I wrote src_install that time when Makefile either was missing or buggy,
anyway, take a notice on conditions)
--
Best regards,
mva
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 23 February 2015 at 01:39, William Hubbs wrote:
> On Sat, Feb 21, 2015 at 09:18:08AM +0100, Michał Górny wrote:
>> neovim:
>>
>> > # Copyright 1999-2015 Gentoo Foundation
>> > # Distributed under the terms of the GNU General Public License v2
>> > # $Header: $
>> >
>> > EAPI=5
>> > inherit cmake-utils flag-o-matic
>> >
>> > DESCRIPTION="Vim's rebirth for the 21st century"
>> > HOMEPAGE="https://github.com/neovim/neovim";
>> > if [[ ${PV} == ]]; then
>> > inherit git-r3
>> > EGIT_REPO_URI="git://github.com/neovim/neovim.git"
>> > KEYWORDS=""
>> > else
>> > inherit vcs-snapshot
>> > COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
>> > SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} ->
>> > ${P}.tar.gz"
>>
>> I don't think relying on stability of generated tarballs is a good
>> idea. The same applies to almost all other ebuilds.
>
> If the tarball is based on an upstream tag, you should be fine, but this
> does not work for a commit hash like what is being used here.
>
> For more info on this, check out the man page for git archive. In
> particular, how it handles timestamps inside the tarball.
>
> In a nutshell, if you use git archive to create a tarball based on a
> commit hash, the time stamps of the files inside the tarball are
> different each time you create it, but this is not true if the tarball
> is based on an upstream tag.
>
> William
Thanks for the explanation! I'll roll tarballs then for our use until
upstream does tags or releases.
--
Cheers,
Ben | yngwin
Gentoo developer
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On Sat, Feb 21, 2015 at 09:18:08AM +0100, Michał Górny wrote:
> neovim:
>
> > # Copyright 1999-2015 Gentoo Foundation
> > # Distributed under the terms of the GNU General Public License v2
> > # $Header: $
> >
> > EAPI=5
> > inherit cmake-utils flag-o-matic
> >
> > DESCRIPTION="Vim's rebirth for the 21st century"
> > HOMEPAGE="https://github.com/neovim/neovim";
> > if [[ ${PV} == ]]; then
> > inherit git-r3
> > EGIT_REPO_URI="git://github.com/neovim/neovim.git"
> > KEYWORDS=""
> > else
> > inherit vcs-snapshot
> > COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
> > SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} ->
> > ${P}.tar.gz"
>
> I don't think relying on stability of generated tarballs is a good
> idea. The same applies to almost all other ebuilds.
If the tarball is based on an upstream tag, you should be fine, but this
does not work for a commit hash like what is being used here.
For more info on this, check out the man page for git archive. In
particular, how it handles timestamps inside the tarball.
In a nutshell, if you use git archive to create a tarball based on a
commit hash, the time stamps of the files inside the tarball are
different each time you create it, but this is not true if the tarball
is based on an upstream tag.
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 02/21/2015 04:05 PM, Michał Górny wrote: >> >> https://bugs.gentoo.org/show_bug.cgi?id=401237 >> >> because Nagios needs libltdl to build. Is that still a problem? > > Yes, it is. Because dev-libs/libltdl. > Thanks, it looks like I investigated the bug on the same day that package was committed. I was revbumping nagios-core today anyway, so I'll fix this at the same time.
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
Dnia 2015-02-21, o godz. 14:43:05
Michael Orlitzky napisał(a):
> On 02/21/2015 03:18 AM, Michał Górny wrote:
> >
> >> DEPEND="${RDEPEND}
> >>sys-devel/libtool
> >
> > Using system-wide libtool is horrendously broken. This is something for
> > upstream to fix (like they should start using a sane build system)
> > but if you really want to commit it like this, already open a bug alike
> > https://bugs.gentoo.org/show_bug.cgi?id=515554.
> >
>
> Bug #515554 is only about /usr/bin/libtool, I think.
Yes.
> I added a
> sys-devel/libtool dependency in,
>
> https://bugs.gentoo.org/show_bug.cgi?id=401237
>
> because Nagios needs libltdl to build. Is that still a problem?
Yes, it is. Because dev-libs/libltdl.
--
Best regards,
Michał Górny
pgp1934fxz0eB.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 02/21/2015 03:18 AM, Michał Górny wrote:
>
>> DEPEND="${RDEPEND}
>> sys-devel/libtool
>
> Using system-wide libtool is horrendously broken. This is something for
> upstream to fix (like they should start using a sane build system)
> but if you really want to commit it like this, already open a bug alike
> https://bugs.gentoo.org/show_bug.cgi?id=515554.
>
Bug #515554 is only about /usr/bin/libtool, I think. I added a
sys-devel/libtool dependency in,
https://bugs.gentoo.org/show_bug.cgi?id=401237
because Nagios needs libltdl to build. Is that still a problem?
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
Dnia 2015-02-22, o godz. 02:19:18
Ben de Groot napisał(a):
> > neovim:
> >
> >> # Copyright 1999-2015 Gentoo Foundation
> >> # Distributed under the terms of the GNU General Public License v2
> >> # $Header: $
> >>
> >> EAPI=5
> >> inherit cmake-utils flag-o-matic
> >>
> >> DESCRIPTION="Vim's rebirth for the 21st century"
> >> HOMEPAGE="https://github.com/neovim/neovim";
> >> if [[ ${PV} == ]]; then
> >> inherit git-r3
> >> EGIT_REPO_URI="git://github.com/neovim/neovim.git"
> >> KEYWORDS=""
> >> else
> >> inherit vcs-snapshot
> >> COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
> >> SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} ->
> >> ${P}.tar.gz"
> >
> > I don't think relying on stability of generated tarballs is a good
> > idea. The same applies to almost all other ebuilds.
>
> Do we often run into trouble with that? I know it's not perfect, but
> it should be temporary, until we get regular releases.
Depends if you belong to the 'I care only about mirrors' camp or the one
that wants SRC_URI to be always correct.
I actually hit the unlucky case when the tarball checksum changed
between ebuild upload and mirror fetching :).
> >> dev-lua/LuaBitOp
> >> dev-lua/lpeg
> >> dev-lua/lua-MessagePack"
> >> DEPEND="${CDEPEND}
> >> virtual/libiconv
> >> virtual/libintl"
> >> RDEPEND="${CDEPEND}
> >> perl? ( dev-lang/perl )
> >> python? ( dev-python/neovim-python-client )"
> >>
> >> src_configure() {
> >> append-cflags "-Wno-error"
> >> append-cppflags "-DNDEBUG -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1"
> >> local mycmakeargs=( -DCMAKE_BUILD_TYPE=Release )
> >
> > That looks like a very bad idea. Doesn't that disable all the Gentoo
> > fancy overrides needed for sane CC/CXX etc.?
>
> Any other way to do that then?
Leave it at default (=Gentoo)?
> >> cmake-utils_src_configure
> >> }
> >
> > And in the end it fails to build with some linker errors like:
> >
> > CMakeFiles/nvim.dir/tui/tui.c.o: In function `tui_set_scroll_region':
> > tui.c:(.text+0xa2): undefined reference to `unibi_get_str'
> > CMakeFiles/nvim.dir/tui/tui.c.o: In function `unibi_set_if_empty':
> > tui.c:(.text+0x40c): undefined reference to `unibi_get_str'
> >
> > or for ncurses, if libtermkey was linked against ncurses. Long story
> > short, it's linking to -ltermkey statically without providing
> > -lunibilium before it... which (static linking) is a horrible thing
> > to do anyway.
>
> WFM, but yeah it's not ideal. I'll contact upstream about it.
It may be a gold linker case.
> >> DEPEND="${RDEPEND}
> >> sys-devel/libtool
> >
> > Using system-wide libtool is horrendously broken. This is something for
> > upstream to fix (like they should start using a sane build system)
> > but if you really want to commit it like this, already open a bug alike
> > https://bugs.gentoo.org/show_bug.cgi?id=515554.
>
> I'll report upstream. Anything else we can do in the meantime?
Well, you can ignore it for now. I was wondering about preparing
a quick tarball with configure.ac to pregenerate libtool for ebuilds
but none of the maintainers replied about needing it. Maybe I should
consider it a QA business :).
> >>
> >> LICENSE="Apache-2.0"
> >> SLOT="0"
> >> KEYWORDS="~amd64 ~x86"
> >> IUSE=""
> >>
> >> DEPEND=">=dev-python/click-3.0
> >> >=dev-python/msgpack-0.4.0
> >> !python_targets_pypy? ( dev-python/greenlet )
> >> !python_targets_python3_4? ( dev-python/trollius )"
> >
> > What?! What are those negative deps supposed to mean?
>
> We need pypy OR greenlet, and python-3.4 OR trollius. This was the
> simplest way I saw to express that.
But if you want both pypy and cpython, you still need greenlet for
cpython. Same for trollius and old versions of python.
> > I'm pretty sure you meant:
> >
> > $(python_gen_cond_dep 'python*' 'dev-python/greenlet[${PYTHON_USEDEP}]')
> > $(python_gen_cond_dep python{2_7,3_2,3_3} 'pypy*'
> > 'dev-python/trollius[${PYTHON_USEDEP}]')
>
> Hmm, black magic?! Tasty!
> After perusing the grimoire--I mean eclass--I get the idea. Thanks for the
> hint!
--
Best regards,
Michał Górny
pgpdp2fCherZV.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 2015-02-21 13:19, Ben de Groot wrote:
> > neovim:
> >
> >> # Copyright 1999-2015 Gentoo Foundation
> >> # Distributed under the terms of the GNU General Public License v2
> >> # $Header: $
> >>
> >> EAPI=5
> >> inherit cmake-utils flag-o-matic
> >>
> >> DESCRIPTION="Vim's rebirth for the 21st century"
> >> HOMEPAGE="https://github.com/neovim/neovim";
> >> if [[ ${PV} == ]]; then
> >> inherit git-r3
> >> EGIT_REPO_URI="git://github.com/neovim/neovim.git"
> >> KEYWORDS=""
> >> else
> >> inherit vcs-snapshot
> >> COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
> >> SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} ->
> >> ${P}.tar.gz"
> >
> > I don't think relying on stability of generated tarballs is a good
> > idea. The same applies to almost all other ebuilds.
> Do we often run into trouble with that? I know it's not perfect, but
> it should be temporary, until we get regular releases.
Personally I'd rather do manual snapshot releases for now. Many vim
packages end up being handled in the same fashion anyway (glance at [1]
for proof).
Tim
[1]: http://dev.gentoo.org/~radhermit/vim/
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 21 February 2015 at 16:18, Michał Górny wrote:
> Hi,
>
> Don't you think it sucks to review a few ebuilds in one e-mail? :)
No. :)
> neovim:
>
>> # Copyright 1999-2015 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Header: $
>>
>> EAPI=5
>> inherit cmake-utils flag-o-matic
>>
>> DESCRIPTION="Vim's rebirth for the 21st century"
>> HOMEPAGE="https://github.com/neovim/neovim";
>> if [[ ${PV} == ]]; then
>> inherit git-r3
>> EGIT_REPO_URI="git://github.com/neovim/neovim.git"
>> KEYWORDS=""
>> else
>> inherit vcs-snapshot
>> COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
>> SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} ->
>> ${P}.tar.gz"
>
> I don't think relying on stability of generated tarballs is a good
> idea. The same applies to almost all other ebuilds.
Do we often run into trouble with that? I know it's not perfect, but
it should be temporary, until we get regular releases.
>> KEYWORDS="~amd64 ~x86"
>> fi
>>
>> LICENSE="Apache-2.0 vim"
>> SLOT="0"
>> IUSE="perl python"
>>
>> CDEPEND="dev-lang/luajit
>> >=dev-libs/libtermkey-0.17
>> >=dev-libs/unibilium-1.1.1
>> >=dev-libs/libuv-1.2.0
>> >=dev-libs/msgpack-0.6.0_pre20150220
>
> Accidentally found trailing whitespace here!
Not present in the actual ebuild.
>> dev-lua/LuaBitOp
>> dev-lua/lpeg
>> dev-lua/lua-MessagePack"
>> DEPEND="${CDEPEND}
>> virtual/libiconv
>> virtual/libintl"
>> RDEPEND="${CDEPEND}
>> perl? ( dev-lang/perl )
>> python? ( dev-python/neovim-python-client )"
>>
>> src_configure() {
>> append-cflags "-Wno-error"
>> append-cppflags "-DNDEBUG -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1"
>> local mycmakeargs=( -DCMAKE_BUILD_TYPE=Release )
>
> That looks like a very bad idea. Doesn't that disable all the Gentoo
> fancy overrides needed for sane CC/CXX etc.?
Any other way to do that then?
>> cmake-utils_src_configure
>> }
>
> And in the end it fails to build with some linker errors like:
>
> CMakeFiles/nvim.dir/tui/tui.c.o: In function `tui_set_scroll_region':
> tui.c:(.text+0xa2): undefined reference to `unibi_get_str'
> CMakeFiles/nvim.dir/tui/tui.c.o: In function `unibi_set_if_empty':
> tui.c:(.text+0x40c): undefined reference to `unibi_get_str'
>
> or for ncurses, if libtermkey was linked against ncurses. Long story
> short, it's linking to -ltermkey statically without providing
> -lunibilium before it... which (static linking) is a horrible thing
> to do anyway.
WFM, but yeah it's not ideal. I'll contact upstream about it.
> libtermkey:
>
>> # Copyright 1999-2015 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Header: $
>>
>> EAPI=5
>> inherit eutils multilib
>>
>> DESCRIPTION="Library for easy processing of keyboard entry from
>> terminal-based programs"
>> HOMEPAGE="http://www.leonerd.org.uk/code/libtermkey/";
>> SRC_URI="http://www.leonerd.org.uk/code/${PN}/${P}.tar.gz";
>>
>> LICENSE="MIT"
>> SLOT="0"
>> KEYWORDS="~amd64 ~x86"
>> IUSE="demos"
>>
>> RDEPEND="|| ( dev-libs/unibilium
>> sys-libs/ncurses[unicode] )"
>
> No, no, no, no, no and no. This dependency is meaningless, and broken.
>
> You're looking for either:
>
> # ignore ncurses since neovim will pull in unibilium anyway,
> # and then libtermkey will prefer it
> RDEPEND="dev-libs/unibilium:="
>
> or a USE flag to toggle the two. No auto-magic || () is doing.
Since neovim upstream now moved completely from ncurses to unibilium,
I guess it makes sense to just do that here too.
>> DEPEND="${RDEPEND}
>> sys-devel/libtool
>
> Using system-wide libtool is horrendously broken. This is something for
> upstream to fix (like they should start using a sane build system)
> but if you really want to commit it like this, already open a bug alike
> https://bugs.gentoo.org/show_bug.cgi?id=515554.
I'll report upstream. Anything else we can do in the meantime?
> The same applies to unibilium.
>
>> virtual/pkgconfig
>> demos? ( dev-libs/glib:2 )"
>>
>> src_prepare() {
>> if ! use demos; then
>> sed -e 's|all: $(LIBRARY) $(DEMOS)|all: $(LIBRARY)|' -i
>> Makefile || die
>
> sed -e '/^all:/s:$(DEMOS)::' ...
>
>> fi
>> }
>>
>> src_compile() {
>> emake PREFIX="${EPREFIX}/usr" all
>
> You need LIBDIR here too, otherwise the executable gets wrong rpath.
ok
> The same applies to unibilium. Also unibilium doesn't respect CC here.
>
>> }
>>
>> src_install() {
>> emake PREFIX="${EPREFIX}/usr" LIBDIR="${EPREFIX}/usr/$(get_libdir)" \
>> DESTDIR="${D}" install
>> prune_libtool_files
>> }
>
> neovim-python-client:
>
>> # Copyright 1999-2015 Gentoo Foundation
>> # Distributed under the terms of the GNU General Public License v2
>> # $Header: $
>>
>> EAPI=5
>> PYTHON_COMPAT=( python{2_7,3_3,3_4} pypy )
>> inherit distutils-r1
>>
>> DESCRIPTION="Python client to conne
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 2/20/15 12:10 PM, Ben de Groot wrote:
> At the suggestion of radhermit, I'm putting my neovim & deps ebuilds
> up here for review, before I commit them to the official tree. Do you
> see any possible improvements?
Overall the ebuilds look nice and clean. Some ideas:
- consider asking libtermkey upstream to provide a way to make demos
optional in a cleaner way than sed over the Makefile
- in neovim-python-client, 0.0.28.tar.gz is hardcoded in the ebuild;
consider using ${PV} instead
Paweł
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
Michał Górny:
>> dev-lua/LuaBitOp
>> dev-lua/lpeg
>> dev-lua/lua-MessagePack"
>> DEPEND="${CDEPEND}
>> virtual/libiconv
>> virtual/libintl"
>> RDEPEND="${CDEPEND}
>> perl? ( dev-lang/perl )
>> python? ( dev-python/neovim-python-client )"
>>
>> src_configure() {
>> append-cflags "-Wno-error"
>> append-cppflags "-DNDEBUG -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1"
>> local mycmakeargs=( -DCMAKE_BUILD_TYPE=Release )
>
> That looks like a very bad idea. Doesn't that disable all the Gentoo
> fancy overrides needed for sane CC/CXX etc.?
>
Not necessarily. It depends on details of the build system. cmake eclass
is a huge hack which works often, but not always.
One should examine the build log.
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
Hi,
Don't you think it sucks to review a few ebuilds in one e-mail? :)
neovim:
> # Copyright 1999-2015 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
>
> EAPI=5
> inherit cmake-utils flag-o-matic
>
> DESCRIPTION="Vim's rebirth for the 21st century"
> HOMEPAGE="https://github.com/neovim/neovim";
> if [[ ${PV} == ]]; then
> inherit git-r3
> EGIT_REPO_URI="git://github.com/neovim/neovim.git"
> KEYWORDS=""
> else
> inherit vcs-snapshot
> COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
> SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} ->
> ${P}.tar.gz"
I don't think relying on stability of generated tarballs is a good
idea. The same applies to almost all other ebuilds.
> KEYWORDS="~amd64 ~x86"
> fi
>
> LICENSE="Apache-2.0 vim"
> SLOT="0"
> IUSE="perl python"
>
> CDEPEND="dev-lang/luajit
> >=dev-libs/libtermkey-0.17
> >=dev-libs/unibilium-1.1.1
> >=dev-libs/libuv-1.2.0
> >=dev-libs/msgpack-0.6.0_pre20150220
Accidentally found trailing whitespace here!
> dev-lua/LuaBitOp
> dev-lua/lpeg
> dev-lua/lua-MessagePack"
> DEPEND="${CDEPEND}
> virtual/libiconv
> virtual/libintl"
> RDEPEND="${CDEPEND}
> perl? ( dev-lang/perl )
> python? ( dev-python/neovim-python-client )"
>
> src_configure() {
> append-cflags "-Wno-error"
> append-cppflags "-DNDEBUG -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1"
> local mycmakeargs=( -DCMAKE_BUILD_TYPE=Release )
That looks like a very bad idea. Doesn't that disable all the Gentoo
fancy overrides needed for sane CC/CXX etc.?
> cmake-utils_src_configure
> }
And in the end it fails to build with some linker errors like:
CMakeFiles/nvim.dir/tui/tui.c.o: In function `tui_set_scroll_region':
tui.c:(.text+0xa2): undefined reference to `unibi_get_str'
CMakeFiles/nvim.dir/tui/tui.c.o: In function `unibi_set_if_empty':
tui.c:(.text+0x40c): undefined reference to `unibi_get_str'
or for ncurses, if libtermkey was linked against ncurses. Long story
short, it's linking to -ltermkey statically without providing
-lunibilium before it... which (static linking) is a horrible thing
to do anyway.
libtermkey:
> # Copyright 1999-2015 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
>
> EAPI=5
> inherit eutils multilib
>
> DESCRIPTION="Library for easy processing of keyboard entry from
> terminal-based programs"
> HOMEPAGE="http://www.leonerd.org.uk/code/libtermkey/";
> SRC_URI="http://www.leonerd.org.uk/code/${PN}/${P}.tar.gz";
>
> LICENSE="MIT"
> SLOT="0"
> KEYWORDS="~amd64 ~x86"
> IUSE="demos"
>
> RDEPEND="|| ( dev-libs/unibilium
> sys-libs/ncurses[unicode] )"
No, no, no, no, no and no. This dependency is meaningless, and broken.
You're looking for either:
# ignore ncurses since neovim will pull in unibilium anyway,
# and then libtermkey will prefer it
RDEPEND="dev-libs/unibilium:="
or a USE flag to toggle the two. No auto-magic || () is doing.
> DEPEND="${RDEPEND}
> sys-devel/libtool
Using system-wide libtool is horrendously broken. This is something for
upstream to fix (like they should start using a sane build system)
but if you really want to commit it like this, already open a bug alike
https://bugs.gentoo.org/show_bug.cgi?id=515554.
The same applies to unibilium.
> virtual/pkgconfig
> demos? ( dev-libs/glib:2 )"
>
> src_prepare() {
> if ! use demos; then
> sed -e 's|all: $(LIBRARY) $(DEMOS)|all: $(LIBRARY)|' -i
> Makefile || die
sed -e '/^all:/s:$(DEMOS)::' ...
> fi
> }
>
> src_compile() {
> emake PREFIX="${EPREFIX}/usr" all
You need LIBDIR here too, otherwise the executable gets wrong rpath.
The same applies to unibilium. Also unibilium doesn't respect CC here.
> }
>
> src_install() {
> emake PREFIX="${EPREFIX}/usr" LIBDIR="${EPREFIX}/usr/$(get_libdir)" \
> DESTDIR="${D}" install
> prune_libtool_files
> }
neovim-python-client:
> # Copyright 1999-2015 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> # $Header: $
>
> EAPI=5
> PYTHON_COMPAT=( python{2_7,3_3,3_4} pypy )
> inherit distutils-r1
>
> DESCRIPTION="Python client to connect to Neovim thru its msgpack-rpc API"
> HOMEPAGE="https://github.com/neovim/python-client";
> SRC_URI="https://github.com/neovim/python-client/archive/0.0.28.tar.gz ->
> ${P}.tar.gz"
Hardcoded PV. And obviously github generated tarball :).
>
> LICENSE="Apache-2.0"
> SLOT="0"
> KEYWORDS="~amd64 ~x86"
> IUSE=""
>
> DEPEND=">=dev-python/click-3.0
> >=dev-python/msgpack-0.4.0
> !python_targets_pypy? ( dev-python/greenlet )
> !python_targets_python3_4? ( dev-python/trollius )"
What?! What are those negative deps supposed to mean?
I'm pretty sure you meant:
$(python_gen_cond_dep 'python*' 'dev-python/greenlet[${PYTHON_USE
[gentoo-dev] [RFC] please review ebuilds for neovim and deps
At the suggestion of radhermit, I'm putting my neovim & deps ebuilds up here for review, before I commit them to the official tree. Do you see any possible improvements? Right now the neovim ebuild does not install any global default nvimrc like we do with vim. We should probably consider doing so. Also, I'm looking for the best way to let neovim use the vim plugins we install in $VIMRUNTIME (such as gentoo-syntax). The ebuilds are available in my personal dev overlay, and I'm attaching them to this mail. -- Cheers, Ben | yngwin Gentoo developer neovim-0.0.0_pre20150220.ebuild Description: Binary data libtermkey-0.17.ebuild Description: Binary data msgpack-0.6.0_pre20150220.ebuild Description: Binary data unibilium-1.1.1.ebuild Description: Binary data lua-MessagePack-0.3.2.ebuild Description: Binary data neovim-python-client-0.0.28.ebuild Description: Binary data trollius-1.0.4.ebuild Description: Binary data
