From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id EE8F6A04DD; Thu, 19 Nov 2020 13:03:35 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D203058C4; Thu, 19 Nov 2020 13:03:34 +0100 (CET) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 44A6C4C96 for ; Thu, 19 Nov 2020 13:03:31 +0100 (CET) IronPort-SDR: hkYzfZyKiQ1o0IfYKmkf0o+XGu4/+I0cd7oI/hEd5DO+rQ3hrT3KT0LS6wVsnrp0xHDaB4UOyh XtQfuuFxEjuA== X-IronPort-AV: E=McAfee;i="6000,8403,9809"; a="167766347" X-IronPort-AV: E=Sophos;i="5.77,490,1596524400"; d="scan'208";a="167766347" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2020 04:03:14 -0800 IronPort-SDR: J0pS3Ms9wlIkksUP338afrs/vpexDAdrfK9Tyu8uprrR4sG7Yx+RmcC/QCL/7szeMIuylTuxL4 d1T0ioBz0VGg== X-IronPort-AV: E=Sophos;i="5.77,490,1596524400"; d="scan'208";a="359950199" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.194.37]) ([10.213.194.37]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Nov 2020 04:03:13 -0800 To: Bruce Richardson Cc: dev@dpdk.org, thomas@monjalon.net References: <027ca076ea8e2be6bd76987da23298ffd5db550f.1605782511.git.anatoly.burakov@intel.com> <20201119112431.GA1829@bricha3-MOBL.ger.corp.intel.com> <20201119114848.GB1829@bricha3-MOBL.ger.corp.intel.com> From: "Burakov, Anatoly" Message-ID: <8a08a33a-b6ab-610e-d0a5-c1dd78bca9ed@intel.com> Date: Thu, 19 Nov 2020 12:03:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201119114848.GB1829@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH] doc: allow sphinx build with no DPDK version X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 19-Nov-20 11:48 AM, Bruce Richardson wrote: > On Thu, Nov 19, 2020 at 11:44:06AM +0000, Burakov, Anatoly wrote: >> On 19-Nov-20 11:24 AM, Bruce Richardson wrote: >>> On Thu, Nov 19, 2020 at 10:41:56AM +0000, Anatoly Burakov wrote: >>>> Currently, when building sphinx documentation, the build will only >>>> succeed if being run from the build system, because the conf.py >>>> script expects DPDK_VERSION environment variable to be set, and >>>> crashes if it is not. >>>> >>>> However, there are certain external tools (such as sphinx >>>> documentation preview extensions for certain IDE's) that use live >>>> preview and thus rely on running their own sphinx commands. In these >>>> cases, it is useful to permit building sphinx documentation without >>>> specifying the DPDK_VERSION environment variable. The version string >>>> is the only thing preventing manual sphinx build commands from >>>> working. >>>> >>>> Fix the conf.py to use "None" as a version string in cases when >>>> DPDK_VERSION environment variable is not set. >>>> >>>> Signed-off-by: Anatoly Burakov --- >>>> doc/guides/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 >>>> deletion(-) >>>> >>>> diff --git a/doc/guides/conf.py b/doc/guides/conf.py index >>>> 9de490e1c4..aceeb62a4f 100644 --- a/doc/guides/conf.py +++ >>>> b/doc/guides/conf.py @@ -36,7 +36,7 @@ html_show_copyright = False >>>> highlight_language = 'none' -release = environ['DPDK_VERSION'] >>>> +release = environ.setdefault('DPDK_VERSION', "None") version = >>>> release >>> >>> Since this is python, we can probably pull the value from the VERSION >>> file on the FS if it's not specified in the environment. However, for >>> now in terms of solving this problem, this version is ok. >>> >>> Acked-by: Bruce Richardson >>> >> >> Yes, we could, and i had that thought. I just decided to keep it simple >> and not depending on FS layout. If there's consensus that picking it up >> from FS is better approach, i can submit a v2. >> > > My view is that it depends on whether you want this considered for 20.11. > If so, I'd suggest that a one-line fix is ok for possible inclusion. For > 21.02, a fuller solution would probably be better. > > /Bruce > It would be nice if this was included in 20.11, so i'll leave it as is :) -- Thanks, Anatoly