From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 353F045712; Fri, 2 Aug 2024 12:48:23 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1767E40B90; Fri, 2 Aug 2024 12:48:23 +0200 (CEST) Received: from mail-ej1-f53.google.com (mail-ej1-f53.google.com [209.85.218.53]) by mails.dpdk.org (Postfix) with ESMTP id E15A940431 for ; Fri, 2 Aug 2024 12:48:21 +0200 (CEST) Received: by mail-ej1-f53.google.com with SMTP id a640c23a62f3a-a7a81bd549eso761701066b.3 for ; Fri, 02 Aug 2024 03:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.tech; s=google; t=1722595701; x=1723200501; darn=dpdk.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=gxJqhES3GDvB5nUJcRzfOqhebf5Jh/skPM0VtDdrNkY=; b=XyuUymNdlqcP7E9nYKWAaHPtVGtJ/I/QvuzEP3VULFX00zL9zmETMMYudjvorUVF7J FSQIOxhXfU8NEIV0I5yN7jxJpF8onCOofHf8idTyTlA3K1vTgykTxqnbhH59NGwgqlIc 7x3rIsRsZ8MkpnaMpoRaf+VFn7sh0m7JBCQUYo7eVRpaKtcAoqXOABvBDFDyJzWjuosi nDtYY8PJgl/4POg2nCjqVLwVKyFWQdtY9SbMj9cI8rX6t5w3GFUrUPdKs67PCYvCszMT 3a5rewTHy5YKO8/deA9bkhXGqTlBcZxXqJ28dB7ZJsH6uU9UzUl199PfyL+L++pTgfOu pv7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722595701; x=1723200501; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gxJqhES3GDvB5nUJcRzfOqhebf5Jh/skPM0VtDdrNkY=; b=inciHtMEn0ilSThaByRIyQvO++nOG9/0Wn7oj01PEQbwFzekeUExgOAeuzmviUMB/0 CMtCzRpoLuV68UK2hiCGmTyvx5syWbFmBDV6QC+XVSyct15lEma7mazQip2P0lQsOTJu y+TTWg8o79ac5jUT9PzuY/qLS7/vWneG30c2HQgcIW9pJGEg2SWhfAfTDY8pMlFJVZkF 8+r0g1OzRbXKpb9F4bboQBnT9JoYZCnBvoTu+r/BwRtdZJkNLRYiLXM7v6ZaHoxo19rG ml1jUY3ae9tfxJaRSdE1+jSa66I4sbtLqQWRsUg8GhkU0fOiPe6uH9snyja+dzFrQG+o Aqlg== X-Forwarded-Encrypted: i=1; AJvYcCUf1gV411hEbGOUzCNqQtNmvyICicqoPmx7oqNCvxRpV7wDE7cDOra5yY69lc+kxxe9tGvNSTE569hcVMQ= X-Gm-Message-State: AOJu0YxPKfsopiwUagI/lI/ihCfzUEas3mDjGPj8CrOyanviH0z6xtgv ppsNGJkJaSNa7lNeIcAAZkishwxvCUYs2cs70nFR4IEYQjLu8A5E6TdS1YpCGaM= X-Google-Smtp-Source: AGHT+IE+C90duqi8+Lld5ua/Dl2uj/Tsyk7HeW04sClAYy29Is5RSpKjkH5UmIfXhQjt0Q8G52ZH/w== X-Received: by 2002:a17:906:6a05:b0:a77:c364:c4f2 with SMTP id a640c23a62f3a-a7dc50a2ecbmr177972266b.52.1722595701203; Fri, 02 Aug 2024 03:48:21 -0700 (PDT) Received: from [192.168.200.22] ([84.245.121.236]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7dc9d88650sm83395066b.152.2024.08.02.03.48.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Aug 2024 03:48:20 -0700 (PDT) Message-ID: <5322c7b0-4935-439b-b8d5-a11bdac15150@pantheon.tech> Date: Fri, 2 Aug 2024 12:48:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 5/5] dts: add API doc generation To: Thomas Monjalon Cc: Honnappa.Nagarahalli@arm.com, bruce.richardson@intel.com, jspewock@iol.unh.edu, probb@iol.unh.edu, paul.szczepanek@arm.com, Luca.Vizzarro@arm.com, npratte@iol.unh.edu, dev@dpdk.org References: <20231115133606.42081-1-juraj.linkes@pantheon.tech> <10378083.0AQdONaE2F@thomas> <9cfefccb-0190-46d3-8942-c8c82da38f99@pantheon.tech> <2336017.ElGaqSPkdT@thomas> Content-Language: en-US From: =?UTF-8?Q?Juraj_Linke=C5=A1?= In-Reply-To: <2336017.ElGaqSPkdT@thomas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 1. 8. 2024 17:07, Thomas Monjalon wrote: > 01/08/2024 15:03, Juraj Linkeš: >> On 30. 7. 2024 15:51, Thomas Monjalon wrote: >>> 12/07/2024 10:57, Juraj Linkeš: >>>> The tool used to generate DTS API docs is Sphinx, which is already in >>>> use in DPDK. The same configuration is used to preserve style with one >>>> DTS-specific configuration (so that the DPDK docs are unchanged) that >>>> modifies how the sidebar displays the content. >>> >>> What is changed in the sidebar? >>> >> >> These are the two changes: >> html_theme_options = { >> 'collapse_navigation': False, >> 'navigation_depth': -1, >> } >> >> The first allows you to explore the structure without needing to enter >> any specific section - it puts the + at each section so everything is >> expandable. >> The second just means that each section can be fully expanded (there's >> no limit). > > OK interesting, you may add a comment # unlimited depth > > Ack. >>>> +# A local reference must be relative to the main index.html page >>>> +# The path below can't be taken from the DTS meson file as that would >>>> +# require recursive subdir traversal (doc, dts, then doc again) >>> >>> This comment is really obscure. >> >> I guess it is. I just wanted to explain that there's not way to do this >> without spelling out the path this way. At least I didn't find a way. >> Should I remove the comment or reword it? > > May be removed I think. > Ok, I'll remove it. >>>> +cdata.set('DTS_API_MAIN_PAGE', join_paths('..', 'dts', 'html', 'index.html')) >>> >>> Oh I think I get it: >>> - DTS_API_MAIN_PAGE is the Meson variable >>> - dts_api_main_page is the Doxygen variable >>> >> >> Yes, this is a way to make it work. Maybe there's something else (I'm >> not that familiar with Doxygen), but from what I can tell, there wasn't >> a command line option that would set a variable (passing the path form >> Meson to Doxygen) and nothing else I found worked. >> >> Is this solution ok? If we want to explore something else, is there >> someone with more experience with Doxygen who could help? > > Yes it's OK like that. > > Ack. >>>> +dts_root = environ.get('DTS_ROOT') >>> >>> Why does it need to be passed as an environment variable? >>> Isn't it a fixed absolute path? >> >> The path to DTS needs to be passed in some way (and added to sys.path) >> so that Sphinx knows where the sources are in order to import them. >> >> Do you want us to not pass the path, but just hardcode it here? I didn't >> really think about that, maybe that could work. > > I think hardcode is better here. > I tried implementing this, but I ran into an issue with this: dts_root = environ.get('DTS_ROOT') if dts_root: path.append(dts_root) # DTS Sidebar config html_theme_options = { 'collapse_navigation': False, 'navigation_depth': -1, } The sidebar configuration is conditional, so we have to pass something to indicate dts build. I'll change it so that we look for 'dts' in src in call-sphinx-build.py (we're in the dts doc directory, indicating dts build) and set the DTS_BUILD env var which we can use in conf.py. I didn't find a better way to do this as conf.py doesn't have any information about the build itself (and no path that conf.py has access to points to anything dts). Here's how it'll look: if environ.get('DTS_BUILD'): path.append(path_join(dirname(dirname(dirname(__file__))), 'dts')) # DTS Sidebar config. html_theme_options = { 'collapse_navigation': False, 'navigation_depth': -1, # unlimited depth } > >>>> +To build DTS API docs, install the dependencies with Poetry, then enter its shell: >>> >>> I don't plan to use Poetry on my machine. >>> Can we simply describe the dependencies even if the versions are not specified? >> >> The reason we don't list the dependencies anywhere is that doing it with >> Poetry is much easier (and a bit safer, as Poetry is going to install >> tested versions). >> >> But I can add references to the two relevant sections of >> dts/pyproject.toml which contain the dependencies with a note that they >> can be installed with pip (and I guess that would be another >> dependency), but at that point it's that not much different than using >> Poetry. > > I want to use my system package manager. > I am from this old school thinking we should have a single package manager in a system. > I understand and would also prefer that, but it just doesn't work for Python. Not all packages are available from the package managers, and Python projects should not use system packages as there are frequently version mismatches between the system packages and what the project needs (the APIs could be different as well as behavior; a problem we've seen with Scapy). Poetry is one of the tools that tries to solve this well-known Python limitation. I've done a quick search of what's available in Ubuntu and two packages aren't available, types-PyYAML (which maybe we could do without, I'll have to test) and aenum (which is currently needed for the capabilities patch; if absolutely necessary, maybe I could find a solution without aenum). But even with this we can't be sure that the system package versions will work. >>>> +.. code-block:: console >>>> + >>>> + poetry install --no-root --with docs >>>> + poetry shell >>>> + >>>> +The documentation is built using the standard DPDK build system. >>>> +After executing the meson command and entering Poetry's shell, build the documentation with: >>>> + >>>> +.. code-block:: console >>>> + >>>> + ninja -C build dts-doc >>> >>> Don't we rely on the Meson option "enable_docs"? >> >> I had a discussion about this with Bruce, but I can't find it anywhere, >> so here's what I remember: >> 1. We didn't want to tie the dts api doc build to dpdk doc build because >> of the dependencies. > > Sure > But we could just skip if dependencies are not met? > Maybe we could add a script that would check the dependencies. I'll see what I can do. >> 2. There's a way to build docs without the enable_docs option (running >> ninja with the target), which is what we added for dts. This doesn't tie >> the dts api doc build to the dpdk doc build. > > Yes > >> 3. We had an "enable_dts_docs" Meson option in the past (to keep it >> separate from dpdk doc build), but decided to drop it. My memory is hazy >> on this, but I think it was, again, because of the additional steps >> needed to bring up the dependency (poetry shell) - at that point, >> supporting just the ninja build way is sufficient. Bruce may shed more >> light on this. > > >>>> + Make sure to fix any Sphinx warnings when adding or updating docstrings, >>>> + and also run the ``devtools/dts-check-format.sh`` script and address any issues it finds. >>> >>> It looks like something to write in the contributing guide. >>> >> >> I could add it there, where is the right place? In patches.rst, section >> "Checking the Patches"? > > Yes > Ack. >