[Buildroot] [RFC] Unification of package comments on wchar, largefile, c++ support, thread, ... support

[Buildroot] [RFC] Unification of package comments on wchar, largefile, c++ support, thread, ... support

[Thomas De Schampheleire]

Hi,

When a package needs any of wchar/largefile/C++/thread support in the
toolchain, this is handled with a comment in Config.in shown when this
condition is not met.

However, the text of these comments is currently not unified, some
examples: (grep -A1 comment package/*/Config.in)

package/acl/Config.in:comment "acl requires a toolchain with LARGEFILE support"
package/acl/Config.in-  depends on !BR2_LARGEFILE
--
package/aircrack-ng/Config.in:comment "aircrack-ng needs a toolchain
with largefile and threads support"
package/aircrack-ng/Config.in-  depends on !BR2_LARGEFILE ||
!BR2_TOOLCHAIN_HAS_THREADS
--
package/alsa-lib/Config.in:comment "alsa-lib needs threads support in toolchain"
package/alsa-lib/Config.in-     depends on !BR2_TOOLCHAIN_HAS_THREADS
--
package/alsamixergui/Config.in:comment "alsamixergui requires a
toolchain with C++ and threads support enabled"
package/alsamixergui/Config.in- depends on (!BR2_INSTALL_LIBSTDCPP ||
!BR2_TOOLCHAIN_HAS_THREADS) && BR2_PACKAGE_XORG7
--
package/atk/Config.in:comment "atk requires a toolchain with WCHAR support"
package/atk/Config.in-  depends on !BR2_USE_WCHAR
--
package/attr/Config.in:comment "attr requires a toolchain with
LARGEFILE support"
package/attr/Config.in- depends on !BR2_LARGEFILE
--
package/audiofile/Config.in:comment "audiofile requires a toolchain
with C++ support enabled"
package/audiofile/Config.in-    depends on !BR2_INSTALL_LIBSTDCPP
--
package/avahi/Config.in:comment "avahi requires a toolchain with thread support"
package/avahi/Config.in-        depends on !BR2_TOOLCHAIN_HAS_THREADS
--
package/axel/Config.in:comment "axel needs a toolchain with thread support"
package/axel/Config.in- depends on !BR2_TOOLCHAIN_HAS_THREADS


As you can see, in just the first few hits of my grep commands, there
are many differences:

- requires vs needs
- LARGEFILE vs largefile (capitalization)
- 'a toolchain with ... support' vs '... support in toolchain'
- thread vs threads
- '... support' vs '... support enabled'
- 'and' vs '+' vs '&' when multiple features are needed (not shown in
the above examples)


I would like to agree on one common text, and adapt all packages
accordingly. The exact wording can be discussed, the main goal is the
unification. Here is a proposal:

foo requires a toolchain with feat support
foo requires a toolchain with featA and featB support
foo requires a toolchain with featA, featB and featC support

where the features would be written as: WCHAR, LARGEFILE, IPV6, RPC,
C++, thread.


What is your opinion on:
a. the concept of this unification
b. the wording proposed above

Thanks,
Thomas

[Buildroot] [RFC] Unification of package comments on wchar, largefile, c++ support, thread, ... support

[Arnout Vandecappelle]

On 19/08/13 17:00, Thomas De Schampheleire wrote:
> Hi,
>
> When a package needs any of wchar/largefile/C++/thread support in the
> toolchain, this is handled with a comment in Config.in shown when this
> condition is not met.
>
> However, the text of these comments is currently not unified, some
> examples: (grep -A1 comment package/*/Config.in)
>
> package/acl/Config.in:comment "acl requires a toolchain with LARGEFILE support"
> package/acl/Config.in-  depends on !BR2_LARGEFILE
> --
> package/aircrack-ng/Config.in:comment "aircrack-ng needs a toolchain
> with largefile and threads support"
> package/aircrack-ng/Config.in-  depends on !BR2_LARGEFILE ||
> !BR2_TOOLCHAIN_HAS_THREADS
> --
> package/alsa-lib/Config.in:comment "alsa-lib needs threads support in toolchain"
> package/alsa-lib/Config.in-     depends on !BR2_TOOLCHAIN_HAS_THREADS
> --
> package/alsamixergui/Config.in:comment "alsamixergui requires a
> toolchain with C++ and threads support enabled"
> package/alsamixergui/Config.in- depends on (!BR2_INSTALL_LIBSTDCPP ||
> !BR2_TOOLCHAIN_HAS_THREADS) && BR2_PACKAGE_XORG7
> --
> package/atk/Config.in:comment "atk requires a toolchain with WCHAR support"
> package/atk/Config.in-  depends on !BR2_USE_WCHAR
> --
> package/attr/Config.in:comment "attr requires a toolchain with
> LARGEFILE support"
> package/attr/Config.in- depends on !BR2_LARGEFILE
> --
> package/audiofile/Config.in:comment "audiofile requires a toolchain
> with C++ support enabled"
> package/audiofile/Config.in-    depends on !BR2_INSTALL_LIBSTDCPP
> --
> package/avahi/Config.in:comment "avahi requires a toolchain with thread support"
> package/avahi/Config.in-        depends on !BR2_TOOLCHAIN_HAS_THREADS
> --
> package/axel/Config.in:comment "axel needs a toolchain with thread support"
> package/axel/Config.in- depends on !BR2_TOOLCHAIN_HAS_THREADS
>
>
> As you can see, in just the first few hits of my grep commands, there
> are many differences:
>
> - requires vs needs
> - LARGEFILE vs largefile (capitalization)
> - 'a toolchain with ... support' vs '... support in toolchain'
> - thread vs threads
> - '... support' vs '... support enabled'
> - 'and' vs '+' vs '&' when multiple features are needed (not shown in
> the above examples)
>
>
> I would like to agree on one common text, and adapt all packages
> accordingly. The exact wording can be discussed, the main goal is the
> unification. Here is a proposal:
>
> foo requires a toolchain with feat support
> foo requires a toolchain with featA and featB support
> foo requires a toolchain with featA, featB and featC support
>
> where the features would be written as: WCHAR, LARGEFILE, IPV6, RPC,
> C++, thread.
>
>
> What is your opinion on:
> a. the concept of this unification
> b. the wording proposed above

  Yes and yes.

  One problem: it has to fit 70 characters.

libfoobarfrobniz requies a toolchain with WCHAR, LARGEFILE, IPV6 and C++ 
support

doesn't fit... But I guess we can make an exception for these rare occasions.

  Regards,
  Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [RFC] Unification of package comments on wchar, largefile, c++ support, thread, ... support

[Alexander Lukichev]

Hi Thomas,

2013/8/19 Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com>

> I would like to agree on one common text, and adapt all packages
> accordingly. The exact wording can be discussed, the main goal is the
> unification. Here is a proposal:
>
> <...>
> What is your opinion on:
> a. the concept of this unification
> b. the wording proposed above
>

I also wondered at the free wording in all the multitude of packages. And
your proposal is a good try to solve the problem. As Arnout has pointed
out, it would also be nice to minimize the comment length, so
  - "needs" looks better than "requires";
  - "support" might well be dropped;
  - "thread" might be changed to "THREADS" if "support" is dropped.

--
Best regards,
  Alexander Lukichev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130821/1624dc42/attachment.html>

[Buildroot] [RFC] Unification of package comments on wchar, largefile, c++ support, thread, ... support

[Thomas De Schampheleire]

All,

On Wed, Aug 21, 2013 at 7:28 AM, Alexander Lukichev
<alexander.lukichev@gmail.com> wrote:
> Hi Thomas,
>
> 2013/8/19 Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com>
>>
>> I would like to agree on one common text, and adapt all packages
>> accordingly. The exact wording can be discussed, the main goal is the
>> unification. Here is a proposal:
>>
>> <...>
>>
>> What is your opinion on:
>> a. the concept of this unification
>> b. the wording proposed above
>
>
> I also wondered at the free wording in all the multitude of packages. And
> your proposal is a good try to solve the problem. As Arnout has pointed out,
> it would also be nice to minimize the comment length, so
>   - "needs" looks better than "requires";
>   - "support" might well be dropped;
>   - "thread" might be changed to "THREADS" if "support" is dropped.
>

I wasn't aware that the 70-character limit is pretty hard, since there
is no horizontal scrolling in menuconfig?

Based on the input of Alexander, here is an alternate, shorter, proposal:

foo needs a toolchain w/ feat
foo needs a toolchain w/ featA, featB
foo needs a toolchain w/ featA, featB, featC

where the features would be written as: WCHAR, LARGEFILE, IPV6, RPC,
C++, THREADS.

The base length of ' needs a toolchain w/ ' is 22 characters.
With the worst case combination of all features (I hope I didn't
forget any), it is:
' needs a toolchain w/ WCHAR, LARGEFILE, IPV6, RPC, C++, THREADS'
which is 63 characters. So this leaves 7 characters for the package
name, which is not a lot.
(note: I also found a package sshfs that checks for static library, so
the string even becomes a bit longer).

However, few packages need all of these features, and therefore I
think that most of them will fit into the 70-chars limit. In the
exceptional case that goes beyond 70 characters, we could still split
the comment over 2 lines.
Besides, who uses 80-char terminals nowadays anyway ;-)

My question to the community: do we agree on the wording above (foo
needs a toolchain w/ XXX, YYY)?
If yes, then I will proceed to making the changes.

Thanks for your input,
Thomas

[Buildroot] [RFC] Unification of package comments on wchar, largefile, c++ support, thread, ... support

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Fri, 6 Sep 2013 12:37:05 +0200, Thomas De Schampheleire wrote:

> My question to the community: do we agree on the wording above (foo
> needs a toolchain w/ XXX, YYY)?
> If yes, then I will proceed to making the changes.

Do we really want to use all uppercase, even for things like thread
support?

We have the choice between:

 (1) All lower-case

 comment "directfb needs a toolchain w/ ipv6, rpc, thread, wchar"

 (2) Lower-case, except when it doesn't make sense (acronyms)

 comment "directfb needs a toolchain w/ IPv6, RPC, thread, wchar"

 (3) All upper-case

 comment "directfb needs a toolchain w/ IPv6, RPC, THREAD, WCHAR"

Also, the other question is which features do we mention. IPv6, RPC,
largefile, wchar, C++ and thread have always been there. However, the
need for dynamic library hasn't been always but in the comments, but
you were suggesting to include it. Also, what about MMU dependency ?

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] [RFC] Unification of package comments on wchar, largefile, c++ support, thread, ... support

[Thomas De Schampheleire]

Hi Thomas,

On Fri, Sep 6, 2013 at 2:28 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear Thomas De Schampheleire,
>
> On Fri, 6 Sep 2013 12:37:05 +0200, Thomas De Schampheleire wrote:
>
>> My question to the community: do we agree on the wording above (foo
>> needs a toolchain w/ XXX, YYY)?
>> If yes, then I will proceed to making the changes.
>
> Do we really want to use all uppercase, even for things like thread
> support?
>
> We have the choice between:
>
>  (1) All lower-case
>
>  comment "directfb needs a toolchain w/ ipv6, rpc, thread, wchar"
>
>  (2) Lower-case, except when it doesn't make sense (acronyms)
>
>  comment "directfb needs a toolchain w/ IPv6, RPC, thread, wchar"
>
>  (3) All upper-case
>
>  comment "directfb needs a toolchain w/ IPv6, RPC, THREAD, WCHAR"

All options are fine for me. I think the most important thing is that
the user can map the comment onto the necessary configuration options
in the toolchain menu.
The second one is most balanced, I'm slightly leaning towards that.

>
> Also, the other question is which features do we mention. IPv6, RPC,
> largefile, wchar, C++ and thread have always been there. However, the
> need for dynamic library hasn't been always but in the comments, but
> you were suggesting to include it. Also, what about MMU dependency ?

I'm not suggesting we should. I saw at least one package that did
mention dynamic library support (sshfs), so I think we should line up:
either mention it when needed (!PREFER_STATIC_LIB) or not mention it
anywhere (and thus change sshfs).
For MMU the same: I'm open for either one, as long as we have a clear
strategy and follow that for all packages.

If you ask my opinion, I would also mention the need for dynamic
library and MMU, but it's not a strong opinion.

Best regards,
Thomas

[Buildroot] [RFC] Unification of package comments on wchar, largefile, c++ support, thread, ... support

[Michael Rommel]

Hi all,

On Sep 6, 2013, at 16:34 , Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote:

>> We have the choice between:
>> 
>> (1) All lower-case
>> 
>> comment "directfb needs a toolchain w/ ipv6, rpc, thread, wchar"
>> 
>> (2) Lower-case, except when it doesn't make sense (acronyms)
>> 
>> comment "directfb needs a toolchain w/ IPv6, RPC, thread, wchar"
>> 
>> (3) All upper-case
>> 
>> comment "directfb needs a toolchain w/ IPv6, RPC, THREAD, WCHAR"
> 
> All options are fine for me. I think the most important thing is that
> the user can map the comment onto the necessary configuration options
> in the toolchain menu.
> The second one is most balanced, I'm slightly leaning towards that.


I would like to have guidance for long package names, too, because I ran into the limit
for python-pyzmq which alone takes up considerable space and I needed three comments
to accommodate all...

  Michael.

-- 
Michael Rommel, Erlangen, Germany

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130906/95e61ffa/attachment.html>