public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Petr Vorel <pvorel@suse.cz>
To: Andrea Cervesato <andrea.cervesato@suse.com>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v3 2/4] doc/Makefile: Allow to create and use .venv
Date: Tue, 25 Mar 2025 10:48:25 +0100	[thread overview]
Message-ID: <20250325094825.GA372417@pevik> (raw)
In-Reply-To: <4c07a227-8fb6-4a9a-b664-d75d726a3d39@suse.com>

Hi Andrea,

first, thanks for your review.

> Hi,

> On 3/25/25 00:40, Petr Vorel wrote:
> > This is an optional target (not run by default).
> > If .venv exists, it's used in other targets.

> > This helps to use virtualenv for development, but avoid using it by
> > default (readthedoc uses container with virtualenv, creating it would be
> > waste of time).

> > Add 'distclean' target which removes also .venv/ directory.

> > Signed-off-by: Petr Vorel <pvorel@suse.cz>
> > ---
> > Changes since v2:
> > * Add distclean in "doc/Makefile: Allow to create and use .venv"

> >   doc/Makefile | 19 +++++++++++++++++--
> >   1 file changed, 17 insertions(+), 2 deletions(-)

> > diff --git a/doc/Makefile b/doc/Makefile
> > index 3c5682ad00..3b8265d88e 100644
> > --- a/doc/Makefile
> > +++ b/doc/Makefile
> > @@ -5,15 +5,30 @@ top_srcdir		?= ..
> >   include $(top_srcdir)/include/mk/env_pre.mk
> > +PYTHON := python3
> > +VENV_DIR := .venv
> > +VENV_CMD := . $(VENV_DIR)/bin/activate
> This will cut off all shells not supporting "activate" script, such as fish
> or csh.

I would guess csh is not much used nowadays in Linux. I would dare to say bash
is much more popular than modern fish (I know more people using zsh), but sure,
how about:

VENV_CMD := . $(VENV_DIR)/bin/activate || . venv/bin/activate.fish

Or even add also activate.csh if you think people are using it.
I would ignore the rest of activate.* scripts

> Quite possible this Makefile would work only on CI, since developers often
> customize their own shells, unless you override VENV_CMD. And, in that case,
> virtualenv creation is 1 command away and it makes this Makefile feature
> superfluous.

I would say in with the above it will work for most of the users (I have heavily
customised shell and venv always worked) and yes, it allows to overwrite.

make VENV_CMD=". .venv/bin/activate.csh"

> > +RUN_VENV := if [ -d $(VENV_DIR) ]; then $(VENV_CMD); fi
> > +
> > +# install sphinx only if needed
> > +INSTALL_SPHINX := $(shell $(PYTHON) -c "import sphinx" 2>/dev/null && echo ":" || echo "pip install sphinx")
> This can be added to requirements.txt, there's no need to handle it in
> Makefile.

I added this as it speeds up the installation. Sure, I can remove it.

> > +
> > +$(VENV_DIR):
> "setup" stage is more clear than using virtualenv directory name.

Using directory name gives us detection if it's needed for free. You complained
about Makefile getting complicated, using setup would complicate it more. Do you
want that?

FYI I expect people will just call 'make doc' in toplevel directory (see
following commits). These people will not even know about name of the .venv
target.

And people doing packaging and still want to build the documentation (IMHO
nobody currently does: SUSE, Buildroot and Yocto), it's still possible via
'make -C doc'.

Kind regards,
Petr

> > +	$(PYTHON) -m virtualenv $(VENV_DIR)
> > +	$(VENV_CMD) && pip install -r requirements.txt && $(INSTALL_SPHINX)
> > +
> >   ${abs_top_builddir}/metadata/ltp.json:
> >   	$(MAKE) -C ${abs_top_builddir}/metadata
> >   all: ${abs_top_builddir}/metadata/ltp.json
> > -	sphinx-build -b html . html
> > +	$(RUN_VENV); sphinx-build -b html . html
> >   spelling:
> > -	sphinx-build -b spelling -d build/doctree . build/spelling
> > +	$(RUN_VENV); sphinx-build -b spelling -d build/doctree . build/spelling
> >   clean:
> >   	rm -rf html/ build/ _static/syscalls.rst _static/tests.rst syscalls.tbl \
> >   		${abs_top_builddir}/metadata/ltp.json
> > +
> > +distclean: clean
> > +	rm -rf $(VENV_DIR)
> Andrea

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

  reply	other threads:[~2025-03-25  9:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-24 23:40 [LTP] [PATCH v3 0/4] Update doc related Makefile Petr Vorel
2025-03-24 23:40 ` [LTP] [PATCH v3 1/4] doc/Makefile: Remove also metadata/ltp.json Petr Vorel
2025-03-24 23:40 ` [LTP] [PATCH v3 2/4] doc/Makefile: Allow to create and use .venv Petr Vorel
2025-03-25  8:35   ` Andrea Cervesato via ltp
2025-03-25  9:48     ` Petr Vorel [this message]
2025-03-27 11:59       ` Andrea Cervesato via ltp
2025-03-27 14:57         ` Petr Vorel
2025-03-27 21:22           ` Andrea Cervesato via ltp
2025-03-24 23:40 ` [LTP] [PATCH v3 3/4] Makefile: Update 'doc' target, add 'doc-clean' Petr Vorel
2025-03-27 11:50   ` Ricardo B. Marli��re via ltp
2025-03-27 11:54     ` Andrea Cervesato via ltp
2025-03-28  8:56       ` Petr Vorel
2025-03-28  9:12     ` Petr Vorel
2025-03-24 23:40 ` [LTP] [PATCH v3 4/4] doc: Note 'make doc' in the building doc 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=20250325094825.GA372417@pevik \
    --to=pvorel@suse.cz \
    --cc=andrea.cervesato@suse.com \
    --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