* [Buildroot] Ncurses wide support
@ 2013-10-15 10:09 Ezequiel García
2013-10-15 10:18 ` Gustavo Zacarias
0 siblings, 1 reply; 11+ messages in thread
From: Ezequiel García @ 2013-10-15 10:09 UTC (permalink / raw)
To: buildroot
Currently Buildroot support building the non-wide (non-unicode) ncurses library.
While ncurses support an easy way to enable wide support with a configure option
(--enable-widec), this option builds *only* the wide-enabled library
(aka libncursesw)
and not the vanilla one.
In other words, it's not possible to build both at the same time.
By looking at my Gentoo ebuild -which is also source based- it seems
they solve this by
simply building ncurses twice: first the vanilla, and then (if unicode
is enabled) the
wide-enabled one.
Questions that arise:
1. Does Buildroot support something like this?
2. Should we patch ncurses configure to change this behavior?
(not really a fun solution, given this is an upstream choice)
3. Do we even care?
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] Ncurses wide support
2013-10-15 10:09 [Buildroot] Ncurses wide support Ezequiel García
@ 2013-10-15 10:18 ` Gustavo Zacarias
2013-10-15 10:48 ` Ezequiel García
0 siblings, 1 reply; 11+ messages in thread
From: Gustavo Zacarias @ 2013-10-15 10:18 UTC (permalink / raw)
To: buildroot
On 10/15/2013 07:09 AM, Ezequiel Garc?a wrote:
> Currently Buildroot support building the non-wide (non-unicode) ncurses library.
>
> While ncurses support an easy way to enable wide support with a configure option
> (--enable-widec), this option builds *only* the wide-enabled library
> (aka libncursesw)
> and not the vanilla one.
>
> In other words, it's not possible to build both at the same time.
>
> By looking at my Gentoo ebuild -which is also source based- it seems
> they solve this by
> simply building ncurses twice: first the vanilla, and then (if unicode
> is enabled) the
> wide-enabled one.
>
> Questions that arise:
>
> 1. Does Buildroot support something like this?
Hi.
There are tricks that could work, for instance by tweaking build and
install cmds you could build and stash the widec version in some new
directory inside the build one, then build the narrow version and
install both - being in another new directory makes it "make clean" safe.
> 2. Should we patch ncurses configure to change this behavior?
> (not really a fun solution, given this is an upstream choice)
Ehh no, probably not.
> 3. Do we even care?
It could be useful for people who want to edit multilanguage stuff in
the target nicely.
Personally i just copy the stuff over from my laptop, there's no
replacement for full vim syntax and rules :)
Regards.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] Ncurses wide support
2013-10-15 10:18 ` Gustavo Zacarias
@ 2013-10-15 10:48 ` Ezequiel García
2013-10-15 11:36 ` Thomas Petazzoni
0 siblings, 1 reply; 11+ messages in thread
From: Ezequiel García @ 2013-10-15 10:48 UTC (permalink / raw)
To: buildroot
Gustavo,
On 15 October 2013 07:18, Gustavo Zacarias <gustavo@zacarias.com.ar> wrote:
> On 10/15/2013 07:09 AM, Ezequiel Garc?a wrote:
>
>> Currently Buildroot support building the non-wide (non-unicode) ncurses library.
>>
>> While ncurses support an easy way to enable wide support with a configure option
>> (--enable-widec), this option builds *only* the wide-enabled library
>> (aka libncursesw)
>> and not the vanilla one.
>>
>> In other words, it's not possible to build both at the same time.
>>
>> By looking at my Gentoo ebuild -which is also source based- it seems
>> they solve this by
>> simply building ncurses twice: first the vanilla, and then (if unicode
>> is enabled) the
>> wide-enabled one.
>>
>> Questions that arise:
>>
>> 1. Does Buildroot support something like this?
>
> Hi.
> There are tricks that could work, for instance by tweaking build and
> install cmds you could build and stash the widec version in some new
> directory inside the build one, then build the narrow version and
> install both - being in another new directory makes it "make clean" safe.
>
Maybe you could explain this in detail? Or draft some ncurses.mk
patch for me to take care of it?
I know you probably don't care about nano, but it's currently broken
because of this ncursesw lack.
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] Ncurses wide support
2013-10-15 10:48 ` Ezequiel García
@ 2013-10-15 11:36 ` Thomas Petazzoni
2013-10-15 11:56 ` Ezequiel García
2013-10-15 11:56 ` Gustavo Zacarias
0 siblings, 2 replies; 11+ messages in thread
From: Thomas Petazzoni @ 2013-10-15 11:36 UTC (permalink / raw)
To: buildroot
Dear Ezequiel Garc?a,
On Tue, 15 Oct 2013 07:48:35 -0300, Ezequiel Garc?a wrote:
> Maybe you could explain this in detail? Or draft some ncurses.mk
> patch for me to take care of it?
>
> I know you probably don't care about nano, but it's currently broken
> because of this ncursesw lack.
Not sure to follow the original problem. If nano needs ncursesw, why
don't you enable wchar support in your toolchain so that ncursesw gets
built?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] Ncurses wide support
2013-10-15 11:36 ` Thomas Petazzoni
@ 2013-10-15 11:56 ` Ezequiel García
2013-10-15 11:56 ` Gustavo Zacarias
1 sibling, 0 replies; 11+ messages in thread
From: Ezequiel García @ 2013-10-15 11:56 UTC (permalink / raw)
To: buildroot
On 15 October 2013 08:36, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Ezequiel Garc?a,
>
> On Tue, 15 Oct 2013 07:48:35 -0300, Ezequiel Garc?a wrote:
>
>> Maybe you could explain this in detail? Or draft some ncurses.mk
>> patch for me to take care of it?
>>
>> I know you probably don't care about nano, but it's currently broken
>> because of this ncursesw lack.
>
> Not sure to follow the original problem. If nano needs ncursesw, why
> don't you enable wchar support in your toolchain so that ncursesw gets
> built?
>
My toolchain *already* has wchar support yet the ncursesw library
is not built (at least over here). It seems like you need to enable it
*explicitly*.
The problem under discussion is that ncurses' --enable-widec option
prevents the non-wide (aka libncurses.so) library from being built.
Hope it's clear now.
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] Ncurses wide support
2013-10-15 11:36 ` Thomas Petazzoni
2013-10-15 11:56 ` Ezequiel García
@ 2013-10-15 11:56 ` Gustavo Zacarias
2013-10-15 11:59 ` Thomas Petazzoni
1 sibling, 1 reply; 11+ messages in thread
From: Gustavo Zacarias @ 2013-10-15 11:56 UTC (permalink / raw)
To: buildroot
On 10/15/2013 08:36 AM, Thomas Petazzoni wrote:
>> Maybe you could explain this in detail? Or draft some ncurses.mk
>> patch for me to take care of it?
>>
>> I know you probably don't care about nano, but it's currently broken
>> because of this ncursesw lack.
>
> Not sure to follow the original problem. If nano needs ncursesw, why
> don't you enable wchar support in your toolchain so that ncursesw gets
> built?
Because ncurses (upstream) just builds the narrow or wide versions, not
both. Currently we build only the narrow version no matter what.
And IIRC some packages don't expect the wide version even if the
toolchain is WCHAR.
Regards.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] Ncurses wide support
2013-10-15 11:56 ` Gustavo Zacarias
@ 2013-10-15 11:59 ` Thomas Petazzoni
2013-10-15 12:01 ` Ezequiel García
2013-10-15 12:02 ` Gustavo Zacarias
0 siblings, 2 replies; 11+ messages in thread
From: Thomas Petazzoni @ 2013-10-15 11:59 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Tue, 15 Oct 2013 08:56:30 -0300, Gustavo Zacarias wrote:
> > Not sure to follow the original problem. If nano needs ncursesw, why
> > don't you enable wchar support in your toolchain so that ncursesw gets
> > built?
>
> Because ncurses (upstream) just builds the narrow or wide versions, not
> both. Currently we build only the narrow version no matter what.
> And IIRC some packages don't expect the wide version even if the
> toolchain is WCHAR.
ncurses is crap :)
A possible solution would be to have a package/ncursesw/ in Buildroot,
that does the same thing as package/ncurses/, but builds the ncursesw
library. This way, packages who want one or the other variant of the
library can have proper dependencies.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] Ncurses wide support
2013-10-15 11:59 ` Thomas Petazzoni
@ 2013-10-15 12:01 ` Ezequiel García
2013-10-15 12:02 ` Gustavo Zacarias
1 sibling, 0 replies; 11+ messages in thread
From: Ezequiel García @ 2013-10-15 12:01 UTC (permalink / raw)
To: buildroot
On 15 October 2013 08:59, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Gustavo Zacarias,
>
> On Tue, 15 Oct 2013 08:56:30 -0300, Gustavo Zacarias wrote:
>
>> > Not sure to follow the original problem. If nano needs ncursesw, why
>> > don't you enable wchar support in your toolchain so that ncursesw gets
>> > built?
>>
>> Because ncurses (upstream) just builds the narrow or wide versions, not
>> both. Currently we build only the narrow version no matter what.
>> And IIRC some packages don't expect the wide version even if the
>> toolchain is WCHAR.
>
> ncurses is crap :)
>
> A possible solution would be to have a package/ncursesw/ in Buildroot,
> that does the same thing as package/ncurses/, but builds the ncursesw
> library. This way, packages who want one or the other variant of the
> library can have proper dependencies.
>
Yes, this should work. But is the added churn is acceptable?
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] Ncurses wide support
2013-10-15 11:59 ` Thomas Petazzoni
2013-10-15 12:01 ` Ezequiel García
@ 2013-10-15 12:02 ` Gustavo Zacarias
2013-10-15 12:04 ` Thomas Petazzoni
1 sibling, 1 reply; 11+ messages in thread
From: Gustavo Zacarias @ 2013-10-15 12:02 UTC (permalink / raw)
To: buildroot
On 10/15/2013 08:59 AM, Thomas Petazzoni wrote:
> ncurses is crap :)
>
> A possible solution would be to have a package/ncursesw/ in Buildroot,
> that does the same thing as package/ncurses/, but builds the ncursesw
> library. This way, packages who want one or the other variant of the
> library can have proper dependencies.
But that would require auditing which packages want/benefit from the
wide version and add some workarounds about that.
Regards.
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] Ncurses wide support
2013-10-15 12:02 ` Gustavo Zacarias
@ 2013-10-15 12:04 ` Thomas Petazzoni
2013-10-15 12:51 ` Thomas De Schampheleire
0 siblings, 1 reply; 11+ messages in thread
From: Thomas Petazzoni @ 2013-10-15 12:04 UTC (permalink / raw)
To: buildroot
Dear Gustavo Zacarias,
On Tue, 15 Oct 2013 09:02:11 -0300, Gustavo Zacarias wrote:
> On 10/15/2013 08:59 AM, Thomas Petazzoni wrote:
>
> > ncurses is crap :)
> >
> > A possible solution would be to have a package/ncursesw/ in Buildroot,
> > that does the same thing as package/ncurses/, but builds the ncursesw
> > library. This way, packages who want one or the other variant of the
> > library can have proper dependencies.
>
> But that would require auditing which packages want/benefit from the
> wide version and add some workarounds about that.
For those who "want" ncursesw, the autobuilders will notice. For those
who would "benefit", then it can just be progressively improved as
users notice such cases.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* [Buildroot] Ncurses wide support
2013-10-15 12:04 ` Thomas Petazzoni
@ 2013-10-15 12:51 ` Thomas De Schampheleire
0 siblings, 0 replies; 11+ messages in thread
From: Thomas De Schampheleire @ 2013-10-15 12:51 UTC (permalink / raw)
To: buildroot
Hi,
On Tue, Oct 15, 2013 at 2:04 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Gustavo Zacarias,
>
> On Tue, 15 Oct 2013 09:02:11 -0300, Gustavo Zacarias wrote:
>> On 10/15/2013 08:59 AM, Thomas Petazzoni wrote:
>>
>> > ncurses is crap :)
>> >
>> > A possible solution would be to have a package/ncursesw/ in Buildroot,
>> > that does the same thing as package/ncurses/, but builds the ncursesw
>> > library. This way, packages who want one or the other variant of the
>> > library can have proper dependencies.
>>
>> But that would require auditing which packages want/benefit from the
>> wide version and add some workarounds about that.
>
> For those who "want" ncursesw, the autobuilders will notice. For those
> who would "benefit", then it can just be progressively improved as
> users notice such cases.
>
If we are to provide two versions of ncurses (narrow, wide) then I
would propose to follow the same principle as for gcc: have one
top-level directory package/ncurses, and inside that provide
ncurses/ncursesw. There will be one common file with the common parts,
and two separate .mk files for the actual packages. This will limit
the amount of code duplication.
Best regards,
Thomas
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-10-15 12:51 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-15 10:09 [Buildroot] Ncurses wide support Ezequiel García
2013-10-15 10:18 ` Gustavo Zacarias
2013-10-15 10:48 ` Ezequiel García
2013-10-15 11:36 ` Thomas Petazzoni
2013-10-15 11:56 ` Ezequiel García
2013-10-15 11:56 ` Gustavo Zacarias
2013-10-15 11:59 ` Thomas Petazzoni
2013-10-15 12:01 ` Ezequiel García
2013-10-15 12:02 ` Gustavo Zacarias
2013-10-15 12:04 ` Thomas Petazzoni
2013-10-15 12:51 ` Thomas De Schampheleire
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox