From: Cyril Hrubis <chrubis@suse.cz>
To: Joerg Vehlow <lkml@jv-coder.de>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 1/1] configure.ac: Fix summary for disabled metadata
Date: Fri, 14 Jan 2022 15:23:19 +0100 [thread overview]
Message-ID: <YeGHV+Gnmo59SXeL@yuki> (raw)
In-Reply-To: <95394feb-6474-d1ca-13d8-3d1c35e781b9@jv-coder.de>
Hi!
> >> Previously with --disable-metadata output didn't mention that metadata
> >> are disabled and printed config which was not used. Now:
> >>
> >> $ ./configure --disable-metadata
> >
> > Slightly off topic, should we rename this to --disable-docparse or
> > --disable-autodoc?
> >
> > Since we split the metadata generator from the documentation and the
> > metadata are now genereated unconditionally...
> >
>
> I would love that and I would reintroduce disable-metadata in that case,
> to completely disable it.
> The question is: Will this break some builds because of semantic changes?
The JSON metadata file is going to replace the runtest files some day,
at least that is the longterm plan. Also the parser that extracts the
metadata from the sources is rather fast, compared to the LTP build and
it's self contained. There is really no reason to have a switch to
disable the metadat extraction step.
The documentation build, on the other hand, is rather slow and requires
asciidoc, which is the reason why there is a switch that can be used to
disable that. The only problem here is that the name is a bit confusing
now.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-01-14 14:21 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 [this message]
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
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=YeGHV+Gnmo59SXeL@yuki \
--to=chrubis@suse.cz \
--cc=lkml@jv-coder.de \
--cc=ltp@lists.linux.it \
/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