* [Buildroot] [git commit] tstools: GitHub migration
@ 2015-10-20 14:33 Peter Korsgaard
2015-10-20 15:14 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: Peter Korsgaard @ 2015-10-20 14:33 UTC (permalink / raw)
To: buildroot
commit: http://git.buildroot.net/buildroot/commit/?id=2c9aceea9014d87aa0852d0e4494559ee634984e
branch: http://git.buildroot.net/buildroot/commit/?id=refs/heads/master
tstools has migrated to GitHub, so let's use this opportuninty to rework
this package as well.
- Change site to GitHub.
- No releases of tags yet, so let's use the latest commit ID from the
master branch as a version.
- There is currently no license file attributed to tstools, so state that
in the tstools.mk file and add empty license file variable. This issue is
being tracked upstream: https://github.com/kynesim/tstools/issues/32
- Wrap the help text in the Config.in to 72 characters, and also change
the project URL to the GitHub one.
- Add a hash file.
- Rename the patch to use a four digit numbering (001 -> 0001).
[Peter: leave license as MPLv1.1, adjust comment to match]
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
---
...h => 0001-build-get-along-with-buildroot.patch} | 0
package/tstools/Config.in | 19 +++++++++----------
package/tstools/tstools.hash | 2 ++
package/tstools/tstools.mk | 11 +++++++----
4 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/package/tstools/001-build-get-along-with-buildroot.patch b/package/tstools/0001-build-get-along-with-buildroot.patch
similarity index 100%
rename from package/tstools/001-build-get-along-with-buildroot.patch
rename to package/tstools/0001-build-get-along-with-buildroot.patch
diff --git a/package/tstools/Config.in b/package/tstools/Config.in
index 706cb54..f5dd138 100644
--- a/package/tstools/Config.in
+++ b/package/tstools/Config.in
@@ -2,16 +2,15 @@ config BR2_PACKAGE_TSTOOLS
bool "tstools"
depends on BR2_USE_MMU # fork()
help
- This is a set of cross-platform command line tools for
- working with MPEG data
+ This is a set of cross-platform command line tools for working with
+ MPEG data.
- The emphasis is on relatively simple tools which concentrate
- on MPEG (H.264 and H.262) data packaged according to H.222
- (i.e., TS or PS), with a particular interest in checking for
- conformance.
+ The emphasis is on relatively simple tools which concentrate on MPEG
+ (H.264 and H.262) data packaged according to H.222 (i.e., TS or PS),
+ with a particular interest in checking for conformance.
- Transport Stream (TS) is typically used for distribution of
- cable and satellite data. Program Stream (PS) is typically
- used to store data on DVDs.
+ Transport Stream (TS) is typically used for distribution of cable
+ and satellite data. Program Stream (PS) is typically used to store
+ data on DVDs.
- https://code.google.com/p/tstools/
+ https://github.com/kynesim/tstools/
diff --git a/package/tstools/tstools.hash b/package/tstools/tstools.hash
new file mode 100644
index 0000000..9b0f1c7
--- /dev/null
+++ b/package/tstools/tstools.hash
@@ -0,0 +1,2 @@
+# Locally calculated
+sha256 3d2b2375e2874933f9aa59d4f25bb6b334747219eb0d7a076974e61222d59bf6 tstools-08f6be304040e7b84760ac3920bcff4a563b6cd2.tar.gz
diff --git a/package/tstools/tstools.mk b/package/tstools/tstools.mk
index 40920d2..3355db8 100644
--- a/package/tstools/tstools.mk
+++ b/package/tstools/tstools.mk
@@ -4,10 +4,13 @@
#
################################################################################
-TSTOOLS_VERSION = 1_11
-TSTOOLS_SITE = https://tstools.googlecode.com/files
-TSTOOLS_SOURCE = tstools-$(TSTOOLS_VERSION).tgz
-TSTOOLS_LICENSE = MPL v1.1
+# No releases or tags yet. Use the latest commit ID from master branch.
+TSTOOLS_VERSION = 08f6be304040e7b84760ac3920bcff4a563b6cd2
+TSTOOLS_SITE = $(call github,kynesim,tstools,$(TSTOOLS_VERSION))
+# tstools upstream doesn't contain any license file so far. See:
+# https://github.com/kynesim/tstools/issues/32
+TSTOOLS_LICENSE = MPLv1.1
+TSTOOLS_LICENSE_FILES =
define TSTOOLS_BUILD_CMDS
$(TARGET_CONFIGURE_OPTS) LD="$(TARGET_CC)" $(TARGET_MAKE_ENV) \
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [Buildroot] [git commit] tstools: GitHub migration
2015-10-20 14:33 [Buildroot] [git commit] tstools: GitHub migration Peter Korsgaard
@ 2015-10-20 15:14 ` Thomas Petazzoni
2015-10-20 15:17 ` Vicente Olivert Riera
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2015-10-20 15:14 UTC (permalink / raw)
To: buildroot
Peter, Vicente,
On Tue, 20 Oct 2015 16:33:07 +0200, Peter Korsgaard wrote:
> - Wrap the help text in the Config.in to 72 characters, and also change
> the project URL to the GitHub one.
Hhh...
> - This is a set of cross-platform command line tools for
> - working with MPEG data
> + This is a set of cross-platform command line tools for working with
> + MPEG data.
This clearly doesn't fit in 72 characters now, except if you count tab
as one character of course. emacs says that the long line here is now
77 characters long.
So basically, the previous wrapping was more correct, IMO.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [git commit] tstools: GitHub migration
2015-10-20 15:14 ` Thomas Petazzoni
@ 2015-10-20 15:17 ` Vicente Olivert Riera
2015-10-20 16:35 ` Yann E. MORIN
0 siblings, 1 reply; 6+ messages in thread
From: Vicente Olivert Riera @ 2015-10-20 15:17 UTC (permalink / raw)
To: buildroot
Hi Thomas,
On 10/20/2015 04:14 PM, Thomas Petazzoni wrote:
> Peter, Vicente,
>
> On Tue, 20 Oct 2015 16:33:07 +0200, Peter Korsgaard wrote:
>
>> - Wrap the help text in the Config.in to 72 characters, and also change
>> the project URL to the GitHub one.
>
> Hhh...
>
>
>> - This is a set of cross-platform command line tools for
>> - working with MPEG data
>> + This is a set of cross-platform command line tools for working with
>> + MPEG data.
>
> This clearly doesn't fit in 72 characters now, except if you count tab
> as one character of course. emacs says that the long line here is now
> 77 characters long.
Yes, I count the tab as 1 character. Shouldn't I?
For me, the tab is 1 character. Then you can set your text editor to
display the tabs as you want. You can display them as 1 space, 2, 3, 4...
Regards,
Vincent.
> So basically, the previous wrapping was more correct, IMO.
>
> Thomas
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [git commit] tstools: GitHub migration
2015-10-20 15:17 ` Vicente Olivert Riera
@ 2015-10-20 16:35 ` Yann E. MORIN
2015-10-20 18:11 ` Peter Korsgaard
0 siblings, 1 reply; 6+ messages in thread
From: Yann E. MORIN @ 2015-10-20 16:35 UTC (permalink / raw)
To: buildroot
Vicente, All,
On 2015-10-20 16:17 +0100, Vicente Olivert Riera spake thusly:
> On 10/20/2015 04:14 PM, Thomas Petazzoni wrote:
> > On Tue, 20 Oct 2015 16:33:07 +0200, Peter Korsgaard wrote:
> >> - This is a set of cross-platform command line tools for
> >> - working with MPEG data
> >> + This is a set of cross-platform command line tools for working with
> >> + MPEG data.
> >
> > This clearly doesn't fit in 72 characters now, except if you count tab
> > as one character of course. emacs says that the long line here is now
> > 77 characters long.
>
> Yes, I count the tab as 1 character. Shouldn't I?
>
> For me, the tab is 1 character. Then you can set your text editor to
> display the tabs as you want. You can display them as 1 space, 2, 3, 4...
A TAB is one byte, but N characters. And in buildroot, we use N=8.
Note: I hate TABs. TABs are so 70s. Besides, since, as you said, the
width of TABs varies very wildely between machines (due to personal
tastes), it means that TABs can not reliably be used to provide a
"beautiful" layout that is reprpducible everywhere as-is; various
editors will always break that nice layout.
Besides, using 8-char-wide TABs means indentation very quickly limits
the amount of space to write code (80-char-wide lines are close to the
optimum width for human reading).
Also, it is very hard to configure one's editor, sicne coding rules vary
between projects, some requiring leading TABs, 4- or 8- (or even 2!)
char wide, while others require leading spaces...
There is today *no* reason to use leading TABs; any sane editor will
happily insert how-many space you want when pressing TAB (heck, I guess
even emacs is capable of that ;-] ).
But since Buildroot has decided to go with leading TABS, and 8-char-wide
TABs, I abide to that rule! ;-)
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [git commit] tstools: GitHub migration
2015-10-20 16:35 ` Yann E. MORIN
@ 2015-10-20 18:11 ` Peter Korsgaard
2015-10-20 18:33 ` Yann E. MORIN
0 siblings, 1 reply; 6+ messages in thread
From: Peter Korsgaard @ 2015-10-20 18:11 UTC (permalink / raw)
To: buildroot
>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
Hi,
> Note: I hate TABs. TABs are so 70s. Besides, since, as you said, the
> width of TABs varies very wildely between machines (due to personal
> tastes), it means that TABs can not reliably be used to provide a
> "beautiful" layout that is reprpducible everywhere as-is; various
> editors will always break that nice layout.
> Besides, using 8-char-wide TABs means indentation very quickly limits
> the amount of space to write code (80-char-wide lines are close to the
> optimum width for human reading).
> Also, it is very hard to configure one's editor, sicne coding rules vary
> between projects, some requiring leading TABs, 4- or 8- (or even 2!)
> char wide, while others require leading spaces...
> There is today *no* reason to use leading TABs; any sane editor will
> happily insert how-many space you want when pressing TAB (heck, I guess
> even emacs is capable of that ;-] ).
While this is all true, Buildroot is mainly Kconfig and Makefiles, and
both of those languages have special handling of tabs, so we have to
stick to it.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] [git commit] tstools: GitHub migration
2015-10-20 18:11 ` Peter Korsgaard
@ 2015-10-20 18:33 ` Yann E. MORIN
0 siblings, 0 replies; 6+ messages in thread
From: Yann E. MORIN @ 2015-10-20 18:33 UTC (permalink / raw)
To: buildroot
Peter, All,
On 2015-10-20 20:11 +0200, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> > Note: I hate TABs. TABs are so 70s. Besides, since, as you said, the
> > width of TABs varies very wildely between machines (due to personal
> > tastes), it means that TABs can not reliably be used to provide a
> > "beautiful" layout that is reprpducible everywhere as-is; various
> > editors will always break that nice layout.
>
> > Besides, using 8-char-wide TABs means indentation very quickly limits
> > the amount of space to write code (80-char-wide lines are close to the
> > optimum width for human reading).
>
> > Also, it is very hard to configure one's editor, sicne coding rules vary
> > between projects, some requiring leading TABs, 4- or 8- (or even 2!)
> > char wide, while others require leading spaces...
>
> > There is today *no* reason to use leading TABs; any sane editor will
> > happily insert how-many space you want when pressing TAB (heck, I guess
> > even emacs is capable of that ;-] ).
>
> While this is all true, Buildroot is mainly Kconfig and Makefiles, and
> both of those languages have special handling of tabs,
Makefile do require TABs (with GNU make that is changeable, btw, but it
gets very confusing very quickly... :-] ).
https://www.gnu.org/software/make/manual/make.html#index-_002eRECIPEPREFIX-_0028change-the-recipe-prefix-character_0029
However, Kconfig has absolutely no requirement that TABs be used. The
only requirements are that config 'options' (bool, help, depends...) be
indented further than the 'config' keyword, and that the help text be
indented further than the 'help' keyword. And such indentation can very
well be spaces. Or TABs. Or both (but consistently, of course).
> so we have to stick to it.
Whether they have those requirements or not, we have to stick to our
coding rules. I never said otherwise. ;-)
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-10-20 18:33 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-20 14:33 [Buildroot] [git commit] tstools: GitHub migration Peter Korsgaard
2015-10-20 15:14 ` Thomas Petazzoni
2015-10-20 15:17 ` Vicente Olivert Riera
2015-10-20 16:35 ` Yann E. MORIN
2015-10-20 18:11 ` Peter Korsgaard
2015-10-20 18:33 ` Yann E. MORIN
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox