Skip to contentSkip to conversation

manual generation: misc changes

PATCH Superseded Thomas De Schampheleire 6 participants 22 messages Sep 19, 2013 – Sep 20, 2013 Kbuild

v1 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#1 lore raw

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)
#2 lore raw

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...

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#3 lore raw

PATCH 1/1 manual generation: change capitalization of messages

In reply to Thomas De Schampheleire
Quoted 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
#4 lore raw

PATCH 1/1 manual generation: update help

In reply to 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'.

---
 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'
#5 lore raw

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'.

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
#6 lore raw

PATCH 1/1 manual generation: update help

In reply to Thomas De Schampheleire
Quoted 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
#7 lore raw

PATCH 1/1 manual generation: check dependencies first

In reply to 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.

---
 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
#8 lore raw

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.

---
 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>
#9 lore raw

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

#10 lore raw

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>

#11 lore raw

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

#12 lore raw

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>

#13 lore raw

PATCH 1/1 manual generation: check dependencies first

In reply to Thomas De Schampheleire

Dear 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
#14 lore raw

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

#15 lore raw

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
#16 lore raw

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
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.

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
#17 lore raw

PATCH 1/1 manual generation: check dependencies first

In reply to Thomas De Schampheleire
Quoted 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.

---
  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
#18 lore raw

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 the

manual"; \
+ 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

#19 lore raw

PATCH 1/1 manual generation: rename manual-txt into manual-text

In reply to 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.

---
 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:
#20 lore raw

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.

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
#21 lore raw

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.

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