manual generation: misc changes
PATCH 1/1 manual generation: misc changes
--- Makefile | 4 ++-- docs/manual/manual.mk | 17 ++++++++++++++--- 2 files changed, 16 insertions(+), 5 deletions(-)
PATCH 1/1 manual generation: change capitalization of messages
When generating the manual, you see following messages:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Generating HTML manual...
Generating Split HTML manual...
Generating PDF manual...
Generating Text manual...
Generating EPUB manual...
and with this patch the capitalization is changed so that it becomes:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Generating HTML manual...
Generating split HTML manual...
Generating PDF manual...
Generating text manual...
Generating ePUB manual...
--- docs/manual/manual.mk | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
docs/manual/manual.mk +3 -3
@@ -43,10 +43,10 @@ endef ################################################################################ define GENDOC $(call GENDOC_INNER,$(1),xhtml,html,html,HTML,--xsltproc-opts "--stringparam toc.section.depth 4") -$(call GENDOC_INNER,$(1),chunked,split-html,chunked,Split HTML,--xsltproc-opts "--stringparam toc.section.depth 4") +$(call GENDOC_INNER,$(1),chunked,split-html,chunked,split HTML,--xsltproc-opts "--stringparam toc.section.depth 4") $(call GENDOC_INNER,$(1),pdf,pdf,pdf,PDF,--dblatex-opts "-P latex.output.revhistory=0") -$(call GENDOC_INNER,$(1),text,txt,text,Text) -$(call GENDOC_INNER,$(1),epub,epub,epub,EPUB) +$(call GENDOC_INNER,$(1),text,txt,text,text) +$(call GENDOC_INNER,$(1),epub,epub,epub,ePUB) clean: $(1)-clean $(1)-clean: $(Q)$(RM) -rf $(O)/docs/$(1)
PATCH 1/1 manual generation: change capitalization of messages
Dear Thomas De Schampheleire,
Quoted 10 lines · Thomas De Schampheleire
When generating the manual, you see following messages:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Generating HTML manual...
Generating Split HTML manual...
Generating PDF manual...
Generating Text manual...
Generating EPUB manual...and with this patch the capitalization is changed so that it becomes:
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Generating HTML manual...
Generating split HTML manual...
Generating PDF manual...
Generating text manual...
Generating ePUB manual...Signed-off-by Thomas De Schampheleire <[email protected]>
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 manual generation: change capitalization of messages
In reply to Thomas De SchampheleireQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Thomas> When generating the manual, you see following messages:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Generating HTML manual...
Generating Split HTML manual...
Generating PDF manual...
Generating Text manual...
Generating EPUB manual...
Thomas> and with this patch the capitalization is changed so that it becomes:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Generating HTML manual...
Generating split HTML manual...
Generating PDF manual...
Generating text manual...
Generating ePUB manual...
Thomas> Signed-off-by: Thomas De Schampheleire <[email protected]>
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 manual generation: update help
In reply to Thomas De SchampheleireThe 'make help' lines for generating the manual did not consider ePub correctly. Instead of providing a limitative list for 'make manual', the text is changed into 'all formats'.
--- Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Makefile +1 -1
@@ -811,7 +811,7 @@ ifeq ($(BR2_TARGET_BAREBOX),y) endif @echo @echo 'Documentation:' - @echo ' manual - build manual in HTML, split HTML, PDF and txt' + @echo ' manual - build manual in all formats' @echo ' manual-html - build manual in HTML' @echo ' manual-split-html - build manual in split HTML' @echo ' manual-pdf - build manual in PDF'
PATCH 1/1 manual generation: update help
Dear Thomas De Schampheleire,
Quoted 5 lines · Thomas De Schampheleire
The 'make help' lines for generating the manual did not consider ePub correctly. Instead of providing a limitative list for 'make manual', the text is changed into 'all formats'.
Signed-off-by Thomas De Schampheleire <[email protected]>
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 manual generation: update help
In reply to Thomas De SchampheleireQuoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Thomas" == Thomas De Schampheleire <[email protected]> writes:
Thomas> The 'make help' lines for generating the manual did not consider ePub correctly. Thomas> Instead of providing a limitative list for 'make manual', the text is changed Thomas> into 'all formats'.
Thomas> Signed-off-by: Thomas De Schampheleire <[email protected]>
Committed, thanks.
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 manual generation: check dependencies first
In reply to Thomas De SchampheleireTo generate the manual, you need asciidoc and w3m. If these are not present, pretty cryptic error messages are given.
This patch adds a simple check for these dependencies, before attempting to build the manual.
--- docs/manual/manual.mk | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)
docs/manual/manual.mk +11 -0
@@ -3,6 +3,16 @@ manual-update-lists: $(Q)BR2_DEFCONFIG="" TOPDIR=$(TOPDIR) O=$(O)/docs/manual/.build \ $(TOPDIR)/support/scripts/gen-manual-lists.py +manual-check-dependencies: + $(Q)if [ -z "`which a2x 2>/dev/null`" ]; then \ + echo "You need asciidoc on your host to generate the manual"; \ + false; \ + fi + $(Q)if [ -z "`which w3m 2>/dev/null`" ]; then \ + echo "You need w3m on your host to generate the manual"; \ + false; \ + fi + ################################################################################ # GENDOC -- generates the make targets needed to build a specific type of # asciidoc documentation.
@@ -24,6 +34,7 @@ define GENDOC_INNER $$(O)/docs/$(1)/$(1).$(4): docs/$(1)/$(1).txt \ $$($(call UPPERCASE,$(1))_SOURCES) \ + manual-check-dependencies \ manual-update-lists $(Q)$(call MESSAGE,"Generating $(5) $(1)...") $(Q)mkdir -p $$(@D)/.build
PATCH 1/1 manual generation: check dependencies first
Thomas, all,
2013/9/19 Thomas De Schampheleire <[email protected]>
Quoted 20 lines
To generate the manual, you need asciidoc and w3m. If these are not present,
pretty cryptic error messages are given.
This patch adds a simple check for these dependencies, before attempting to build the manual.Signed-off-by Thomas De Schampheleire <[email protected]>--- docs/manual/manual.mk | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)docs/manual/manual.mk +1
-0@@ -3,6 +3,16 @@ manual-update-lists: $(Q)BR2_DEFCONFIG="" TOPDIR=$(TOPDIR) O=$(O)/docs/manual/.build \ $(TOPDIR)/support/scripts/gen-manual-lists.py +manual-check-dependencies:
docs/manual/manual.mk manual-update-lists: · line 16
Quoted 10 lines
docs/manual/manual.mk +8
-0+ $(Q)if [ -z "`which a2x 2>/dev/null`" ]; then \ + echo "You need asciidoc on your host to generate the manual"; \ + false; \ + fi + $(Q)if [ -z "`which w3m 2>/dev/null`" ]; then \ + echo "You need w3m on your host to generate the manual"; \ + false; \ + fi
To generate the pdf manual, you need dblatex too.
Also, to update the lists of the manual, you need python with argparse package.
Quoted 7 lines
docs/manual/manual.mk +1
-0+################################################################################
# GENDOC -- generates the make targets needed to build a specific type of
# asciidoc documentation.
docs/manual/manual.mk define GENDOC_INNER · line 40
Quoted 7 lines
docs/manual/manual.mk +1
-0@@ -24,6 +34,7 @@ define GENDOC_INNER $$(O)/docs/$(1)/$(1).$(4): docs/$(1)/$(1).txt \ $$($(call UPPERCASE,$(1))_SOURCES) \ + manual-check-dependencies \ manual-update-lists $(Q)$(call MESSAGE,"Generating $(5) $(1)...") $(Q)mkdir -p $$(@D)/.build
Regards,
Signature · 4 lines
Samuel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130919/e84d53e4/attachment.html>
PATCH 1/1 manual generation: check dependencies first
Quoted 2 lines · Samuel Martin
Thomas, all,
[..]
Quoted 2 lines
To generate the pdf manual, you need dblatex too.
dblatex was installed by default, it seems, on my Ubuntu-based system. How would you like to check this? We can add it to the proposed manual-check-dependencies rule, but this means that even if you're only interested in the text manual you need to install dblatex. Alternatively, we can add an explicit dependency like:
manual-pdf: manual-check-pdf-dependency
but this kind of conflicts with the generic gendoc principle currently used.
Quoted 3 lines
Also, to update the lists of the manual, you need python with argparse package.
For python, should we check and bail out, or rather skip the package list generation? In fact, why is the package list generation coupled to the manual?
If we do want to check for python, should we simply check for the python version 2.7+ or 3.2+ in which argparse was introduced, or are you thinking about a more elaborate check on argparse?
Thanks,
Thomas
PATCH 1/1 manual generation: check dependencies first
Thomas De Schampheleire,
Thomas De Schampheleire <[email protected]> wrote on 09/19/2013 08:30:25 AM:
Quoted 1 line
On Thu, Sep 19, 2013 at 1:43 PM, Samuel Martin <[email protected]>
Quoted 6 lines · wrote:
Quoted 2 lines
Thomas, all,
[..]
Quoted 2 lines
To generate the pdf manual, you need dblatex too.
Quoted 7 lines
dblatex was installed by default, it seems, on my Ubuntu-based system. How would you like to check this? We can add it to the proposed manual-check-dependencies rule, but this means that even if you're only interested in the text manual you need to install dblatex. Alternatively, we can add an explicit dependency like:
manual-pdf: manual-check-pdf-dependency
but this kind of conflicts with the generic gendoc principle currently
used.
I was also going to to add to the documentation the versions of the Ubuntu packages that I got the manual to build with. Ubuntu version + package version so that way in the manual we can give a reference system configuration that we say builds the manual. For Ubuntu 10.04 I was having issues building the manual but with Ubuntu 12.04 I could successfully build
everything.
I haven't had a chance to get around to doing this yet so I don't know if you want to add your Ubuntu configuration as a reference configuration for generating the manual under Section 3.2? Maybe this warrants a subsection (3.2.1) in manual for generating the manual? If you don't get around to doing this, I will when I get around to adding some documentation to the regarding SELinux and information about patch reviews.
Quoted 11 lines
Quoted 3 lines
Also, to update the lists of the manual, you need python with argparse package.
For python, should we check and bail out, or rather skip the package list generation? In fact, why is the package list generation coupled to the manual?
If we do want to check for python, should we simply check for the python version 2.7+ or 3.2+ in which argparse was introduced, or are you thinking about a more elaborate check on argparse?
Quoted 2 lines
Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130919/44b897bc/attachment.html>
PATCH 1/1 manual generation: check dependencies first
Hi Ryan,
Quoted 9 lines · Ryan Barnett
I was also going to to add to the documentation the versions of the Ubuntu packages that I got the manual to build with. Ubuntu version + package version so that way in the manual we can give a reference system configuration that we say builds the manual. For Ubuntu 10.04 I was having issues building the manual but with Ubuntu 12.04 I could successfully build everything.
Quoted 6 lines
I haven't had a chance to get around to doing this yet so I don't know if you want to add your Ubuntu configuration as a reference configuration for generating the manual under Section 3.2? Maybe this warrants a subsection (3.2.1) in manual for generating the manual? If you don't get around to doing this, I will when I get around to adding some documentation to the regarding SELinux and information about patch reviews.
I'm wondering whether this is very useful. A user will not install another Linux distribution just to build the buildroot manual, so the Ubuntu version doesn't seem necessary to me. The package version only seems relevant in case we know that some versions give problems for building the manual. But unless we have some more info on that, I would not add such info to the manual (also because it is very quickly out-of-date).
For the problems you saw on Ubuntu 10.04, there may be a solution with asciidoc 8.6.3, as I just posted in your original thread. If this could be verified, then we could update the manual with just that.
Best regards,
Thomas
PATCH 1/1 manual generation: check dependencies first
Thomas,
Thomas De Schampheleire <[email protected]> wrote on 09/19/2013 10:08:03 AM:
Quoted 7 lines
Hi Ryan,
Quoted 3 lines · Ryan Barnett
I was also going to to add to the documentation the versions of the
Ubuntu
Quoted 3 lines
Quoted 3 lines
packages that I got the manual to build with. Ubuntu version + package version so that way in the manual we can give a reference system configuration that we say builds the manual. For Ubuntu 10.04 I was
having
Quoted 1 line
Quoted 1 line
issues building the manual but with Ubuntu 12.04 I could successfully
build
Quoted 3 lines
Quoted 3 lines
everything.
I haven't had a chance to get around to doing this yet so I don't know
if
Quoted 1 line
Quoted 1 line
you want to add your Ubuntu configuration as a reference configuration
for
Quoted 1 line
Quoted 1 line
generating the manual under Section 3.2? Maybe this warrants a
subsection
Quoted 1 line
Quoted 1 line
(3.2.1) in manual for generating the manual? If you don't get around
to
Quoted 1 line
Quoted 1 line
doing this, I will when I get around to adding some documentation to
the
Quoted 9 lines
Quoted 1 line
regarding SELinux and information about patch reviews.
I'm wondering whether this is very useful. A user will not install another Linux distribution just to build the buildroot manual, so the Ubuntu version doesn't seem necessary to me. The package version only seems relevant in case we know that some versions give problems for building the manual. But unless we have some more info on that, I would not add such info to the manual (also because it is very quickly out-of-date).
I'm sorry I misspoke and I do agree with you that we should just give the version of asciidoc/w3m/(don't remember the other packages). After I sent the previous message I figured that wasn't good idea. But I still think that it would be helpful to have the versions of the tools that are used and the version for which they are known to work for.
Quoted 3 lines
For the problems you saw on Ubuntu 10.04, there may be a solution with asciidoc 8.6.3, as I just posted in your original thread. If this could be verified, then we could update the manual with just that.
Thanks - I never really had time to track down the solution or what version issue was fixed at. I've replied with the information to the email on that original thread.
Quoted 3 lines
Best regards,
Thomas
Thanks,
-Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130919/cdd4943d/attachment.html>
PATCH 1/1 manual generation: check dependencies first
In reply to Thomas De SchampheleireDear Thomas De Schampheleire,
Quoted 3 lines · Thomas De Schampheleire
For python, should we check and bail out, or rather skip the package list generation? In fact, why is the package list generation coupled to the manual?
Because the package list is used in the manual only, and the best moment to generate is when building the manual?
When would you want to generate it?
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 manual generation: check dependencies first
Quoted 4 lines · Thomas Petazzoni
Dear Thomas De Schampheleire,
On Thu, 19 Sep 2013 15:30:25 +0200, Thomas De Schampheleire wrote:
Quoted 8 lines
Quoted 3 lines
For python, should we check and bail out, or rather skip the package list generation? In fact, why is the package list generation coupled to the manual?
Because the package list is used in the manual only, and the best moment to generate is when building the manual?
When would you want to generate it?
I was thinking it could become a separate build target. But at that time I didn't fully realize (and didn't check) that these lists are actually included in the manual. So, that question is void now.
Remains: how should we check for python argparse? Module argparse is included from python-2.7 and python-3.2 onwards. It seems that Ubuntu has been providing python-argparse for older python versions as well, but IMO it is not needed to check for this explicitly. If you ask me, I would simply check for python 2.7+ and 3.2+, but I'm open for discussion.
Thanks,
Thomas
PATCH 1/1 manual generation: check dependencies first
Dear Thomas De Schampheleire,
Quoted 3 lines · Thomas De Schampheleire
I was thinking it could become a separate build target. But at that time I didn't fully realize (and didn't check) that these lists are actually included in the manual. So, that question is void now.
No problem :)
Quoted 6 lines
Remains: how should we check for python argparse? Module argparse is included from python-2.7 and python-3.2 onwards. It seems that Ubuntu has been providing python-argparse for older python versions as well, but IMO it is not needed to check for this explicitly. If you ask me, I would simply check for python 2.7+ and 3.2+, but I'm open for discussion.
if ! python -c "import argparse" >/dev/null 2>&1 ; then
echo "No Python, or argparse not available" exit 1
fi
something like that, no? It would cover both cases were argparse is part of the default Python installation and the cases were argparse was installed separately.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 manual generation: check dependencies first
Quoted 17 lines · Thomas Petazzoni
Dear Thomas De Schampheleire,
Quoted 3 lines · Thomas De Schampheleire
I was thinking it could become a separate build target. But at that time I didn't fully realize (and didn't check) that these lists are actually included in the manual. So, that question is void now.
No problem :)
Quoted 6 lines
Remains: how should we check for python argparse? Module argparse is included from python-2.7 and python-3.2 onwards. It seems that Ubuntu has been providing python-argparse for older python versions as well, but IMO it is not needed to check for this explicitly. If you ask me, I would simply check for python 2.7+ and 3.2+, but I'm open for discussion.
Quoted 8 lines
if ! python -c "import argparse" >/dev/null 2>&1 ; then
echo "No Python, or argparse not available" exit 1
fisomething like that, no? It would cover both cases were argparse is part of the default Python installation and the cases were argparse was installed separately.
You could also download https://argparse.googlecode.com/hg/argparse.py
if needed, or include it in buildroot and at the following to the python script:
try:
import argparse
except:
import compat_argparse as argparse
Unfortunately that only works down to python 2.5 - argparse.py is not
compatible with 2.4 or earlier.
Or, you could convert the script to optparse :-)
Regards,
Arnout
Signature · 6 lines
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
PATCH 1/1 manual generation: check dependencies first
In reply to Thomas De SchampheleireQuoted 15 lines · Thomas De Schampheleire
To generate the manual, you need asciidoc and w3m. If these are not present, pretty cryptic error messages are given.
This patch adds a simple check for these dependencies, before attempting to build the manual.Signed-off-by Thomas De Schampheleire <[email protected]>--- docs/manual/manual.mk | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)
docs/manual/manual.mk manual-update-lists: · line 9
Quoted 7 lines
docs/manual/manual.mk +4
-0@@ -3,6 +3,16 @@ manual-update-lists: $(Q)BR2_DEFCONFIG="" TOPDIR=$(TOPDIR) O=$(O)/docs/manual/.build \ $(TOPDIR)/support/scripts/gen-manual-lists.py +manual-check-dependencies: + $(Q)if [ -z "`which a2x 2>/dev/null`" ]; then \ + echo "You need asciidoc on your host to generate the manual"; \ + false; \
I don't think this works. I think you need "exit 1;".
Regards,
Arnout
Quoted 22 lines
docs/manual/manual.mk +7
-0+ fi + $(Q)if [ -z "`which w3m 2>/dev/null`" ]; then \ + echo "You need w3m on your host to generate the manual"; \ + false; \ + fi + ################################################################################ # GENDOC -- generates the make targets needed to build a specific type of # asciidoc documentation.@@ -24,6 +34,7 @@ define GENDOC_INNER $$(O)/docs/$(1)/$(1).$(4): docs/$(1)/$(1).txt \ $$($(call UPPERCASE,$(1))_SOURCES) \ + manual-check-dependencies \ manual-update-lists $(Q)$(call MESSAGE,"Generating $(5) $(1)...") $(Q)mkdir -p $$(@D)/.build_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
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
PATCH 1/1 manual generation: check dependencies first
Hi Arnout,
Quoted 11 lines · Arnout Vandecappelle
Quoted 5 lines · Thomas De Schampheleire
docs/manual/manual.mk +3
-0+manual-check-dependencies: + $(Q)if [ -z "`which a2x 2>/dev/null`" ]; then \ + echo "You need asciidoc on your host to generate themanual"; \
+ false; \I don't think this works. I think you need "exit 1;".
It does work in fact, because the return code of the if statement is false (the last statement within it) and the two ifs are not chained in one subshell. Hence, make stops at the first failing command (the first failing if).
But it's a fragile construction, because if someone later decides to chain both ifs in one subshell, then it stops working. So I will indeed change it to exit 1.
Best regards,
Thomas
PATCH 1/1 manual generation: rename manual-txt into manual-text
In reply to Thomas De SchampheleireThe output extension and the generation messages refer to 'text', but the make target was confusingly 'txt'. This patch changes the make target for consistency.
--- docs/manual/manual.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Makefile +1 -1
@@ -815,7 +815,7 @@ endif @echo ' manual-html - build manual in HTML' @echo ' manual-split-html - build manual in split HTML' @echo ' manual-pdf - build manual in PDF' - @echo ' manual-txt - build manual in txt' + @echo ' manual-text - build manual in text' @echo ' manual-epub - build manual in ePub' @echo @echo 'Miscellaneous:'
docs/manual/manual.mk +1 -1
@@ -56,7 +56,7 @@ define GENDOC $(call GENDOC_INNER,$(1),xhtml,html,html,HTML,--xsltproc-opts "--stringparam toc.section.depth 4") $(call GENDOC_INNER,$(1),chunked,split-html,chunked,split HTML,--xsltproc-opts "--stringparam toc.section.depth 4") $(call GENDOC_INNER,$(1),pdf,pdf,pdf,PDF,--dblatex-opts "-P latex.output.revhistory=0") -$(call GENDOC_INNER,$(1),text,txt,text,text) +$(call GENDOC_INNER,$(1),text,text,text,text) $(call GENDOC_INNER,$(1),epub,epub,epub,ePUB) clean: $(1)-clean $(1)-clean:
PATCH 1/1 manual generation: rename manual-txt into manual-text
Dear Thomas De Schampheleire,
Quoted 5 lines · Thomas De Schampheleire
The output extension and the generation messages refer to 'text', but the make target was confusingly 'txt'. This patch changes the make target for consistency.
Signed-off-by Thomas De Schampheleire <[email protected]>
That's a change in the Buildroot interface, but I believe it's ok. However, you're not updating another occurrence of manual-txt in the main Makefile (see the release target).
Thanks,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
PATCH 1/1 manual generation: rename manual-txt into manual-text
Hi Thomas,
Quoted 10 lines · Thomas Petazzoni
Dear Thomas De Schampheleire,
Quoted 5 lines · Thomas De Schampheleire
The output extension and the generation messages refer to 'text', but the make target was confusingly 'txt'. This patch changes the make target for consistency.
Signed-off-by Thomas De Schampheleire <[email protected]>That's a change in the Buildroot interface, but I believe it's ok.
True. I figured that the manual is built only rarely (many people are using the release tarballs), let alone that manual-txt is explicitly called. People that do build manual-txt are often buildroot developers, and hopefully they are flexible enough :-)
Quoted 2 lines
However, you're not updating another occurrence of manual-txt in the main
Makefile(see the release target).
Ai, sorry, I didn't think of that. Will fix.
Thanks for your feedback,
Thomas