From: Cyril Hrubis <chrubis@suse.cz>
To: Petr Vorel <pvorel@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/1] configure.ac: Fix summary for disabled metadata
Date: Tue, 18 Jan 2022 17:07:18 +0100 [thread overview]
Message-ID: <YebltjyJfw4CQnVK@yuki> (raw)
In-Reply-To: <Yebhgmc0e8hWtmPM@pevik>
Hi!
> > Don't we stil have the same problem with "$enable_metadata_html" and
> > "$enable_metadata_pdf" ?
> Well, this patch was about configure output. I wouldn't print them at all if
> metadata disabled. They're not used anyway in the code if metadata disabled.
I guess that I'm still confused by the configure script, because we do
use enable_metadata_html and enable_metadata_pdf but I do not get how
the enable_metadata works, we do not seem to use it for anything but
perl module check in there.
What I would have expected there would be:
diff --git a/m4/ltp-docparse.m4 b/m4/ltp-docparse.m4
index 88d2e08e4..6f0bef1c9 100644
--- a/m4/ltp-docparse.m4
+++ b/m4/ltp-docparse.m4
@@ -35,7 +35,12 @@ with_metadata=no
with_metadata_html=no
with_metadata_pdf=no
-if test "x$enable_metadata" = xyes && test "x$enable_metadata_html" = xyes -o "x$enable_metadata_pdf" = xyes; then
+if test "x$enable_metadata" != xyes; then
+ enable_metadata_html=no
+ enable_metadata_pdf=no
+fi
+
+if test "x$enable_metadata_html" = xyes -o "x$enable_metadata_pdf" = xyes; then
AX_PROG_PERL_MODULES(Cwd File::Basename JSON LWP::Simple)
fi
And that would cause both with_metadata_html and with_metadata_pdf to be
set to 'no' and the configure summary would be correct to begin with.
> > I think that we should rethink what the flags really do, I guess that
> > for instance it would make sense for the $enable_metadata=no to just set
> > both $enable_metadata_html and $enable_metadata_pdf to no and the rest
> > of the m4/ltp-docparse.m4 should just check the later two.
> Rethink the flags meaning or a functionality?
>
> And how about flags names? What name would you suggest?
> --disable-doc, --with-html-doc, --with-pdf-doc ?
> Because we now have metadata (i.e. JSON output) mandatory.
I guess that I would call this 'autodoc' or 'docparse' or something
that describes that it's generated documentation.
> I wonder what is needed to be fixed now and what's better to postpone after the
> release?
Depends on the size of the patch, if it's small enough, like the one I
posted above it should be okay.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-01-18 16:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 12:55 [LTP] [PATCH 1/1] configure.ac: Fix summary for disabled metadata Petr Vorel
2022-01-14 13:12 ` Joerg Vehlow
2022-01-14 14:12 ` Cyril Hrubis
2022-01-14 14:16 ` Joerg Vehlow
2022-01-14 14:23 ` Cyril Hrubis
2022-01-14 14:27 ` Joerg Vehlow
2022-01-14 14:51 ` Cyril Hrubis
2022-01-14 17:54 ` Petr Vorel
2022-01-14 17:44 ` Petr Vorel
2022-01-18 15:12 ` Cyril Hrubis
2022-01-18 15:49 ` Petr Vorel
2022-01-18 16:07 ` Cyril Hrubis [this message]
2022-01-18 16:47 ` Petr Vorel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YebltjyJfw4CQnVK@yuki \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=pvorel@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox