Message ID | 246bed054da59d6508dc.1379587635@argentina |
---|---|
State | Superseded |
Headers | show |
Thomas, all, 2013/9/19 Thomas De Schampheleire <patrickdepinguin@gmail.com> > 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 <thomas.de.schampheleire@gmail.com> > > --- > docs/manual/manual.mk | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/docs/manual/manual.mk b/docs/manual/manual.mk > --- a/docs/manual/manual.mk > +++ b/docs/manual/manual.mk > @@ -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 > To generate the pdf manual, you need dblatex too. Also, to update the lists of the manual, you need python with argparse package. > + > > ################################################################################ > # 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 > Regards,
On Thu, Sep 19, 2013 at 1:43 PM, Samuel Martin <s.martin49@gmail.com> wrote: > Thomas, all, > [..] > > 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. > 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
Thomas De Schampheleire, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote on 09/19/2013 08:30:25 AM: > On Thu, Sep 19, 2013 at 1:43 PM, Samuel Martin <s.martin49@gmail.com> wrote: > > Thomas, all, > > > [..] > > > > 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. 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. > > 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
Hi Ryan, On Thu, Sep 19, 2013 at 4:28 PM, Ryan Barnett <rjbarnet@rockwellcollins.com> wrote: > > > 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. 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
Thomas, Thomas De Schampheleire <patrickdepinguin@gmail.com> wrote on 09/19/2013 10:08:03 AM: > Hi Ryan, > > On Thu, Sep 19, 2013 at 4:28 PM, Ryan Barnett > <rjbarnet@rockwellcollins.com> wrote: > > > > > > 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. > > 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. > 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. > > Best regards, > Thomas Thanks, -Ryan
Dear Thomas De Schampheleire, On Thu, 19 Sep 2013 15:30:25 +0200, Thomas De Schampheleire wrote: > 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
On Thu, Sep 19, 2013 at 5:39 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Dear Thomas De Schampheleire, > > On Thu, 19 Sep 2013 15:30:25 +0200, Thomas De Schampheleire wrote: > >> 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
Dear Thomas De Schampheleire, On Thu, 19 Sep 2013 18:27:34 +0200, Thomas De Schampheleire wrote: > 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 :) > 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
On 19/09/13 20:57, Thomas Petazzoni wrote: > Dear Thomas De Schampheleire, > > On Thu, 19 Sep 2013 18:27:34 +0200, Thomas De Schampheleire wrote: > >> 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 :) > >> 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. 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
On 19/09/13 12:47, Thomas De Schampheleire wrote: > 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 <thomas.de.schampheleire@gmail.com> > > --- > docs/manual/manual.mk | 11 +++++++++++ > 1 files changed, 11 insertions(+), 0 deletions(-) > > diff --git a/docs/manual/manual.mk b/docs/manual/manual.mk > --- a/docs/manual/manual.mk > +++ b/docs/manual/manual.mk > @@ -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 > + 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@busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot >
Hi Arnout, On Thu, Sep 19, 2013 at 9:30 PM, Arnout Vandecappelle <arnout@mind.be> wrote: > On 19/09/13 12:47, Thomas De Schampheleire wrote: >> +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
diff --git a/docs/manual/manual.mk b/docs/manual/manual.mk --- a/docs/manual/manual.mk +++ b/docs/manual/manual.mk @@ -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
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 <thomas.de.schampheleire@gmail.com> --- docs/manual/manual.mk | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-)