From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by inbox.dpdk.org (Postfix) with ESMTP id 9F973A04DD;
Thu, 19 Nov 2020 12:44:15 +0100 (CET)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 0EBC2592C;
Thu, 19 Nov 2020 12:44:14 +0100 (CET)
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
by dpdk.org (Postfix) with ESMTP id AE93158C4
for <dev@dpdk.org>; Thu, 19 Nov 2020 12:44:11 +0100 (CET)
IronPort-SDR: NQ7Cl4gC1lEYLsSvWDl+wGK+aHOU2MDmMbU6GJzDjxM58hK5sWBL1ZUwpeNL2eZvIDOmr/Vl5z
3QqjD2riI+Vw==
X-IronPort-AV: E=McAfee;i="6000,8403,9809"; a="170493214"
X-IronPort-AV: E=Sophos;i="5.77,490,1596524400"; d="scan'208";a="170493214"
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga004.fm.intel.com ([10.253.24.48])
by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;
19 Nov 2020 03:44:09 -0800
IronPort-SDR: XlrG9/2p6G5voZtq7oyY+mrV57CTZJs/7JSncr0UWIdXiF3kcvy8bEnWM7Mriw1XCiaH2McLk7
ewK8rTsWCcQg==
X-IronPort-AV: E=Sophos;i="5.77,490,1596524400"; d="scan'208";a="359943417"
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 03:44:08 -0800
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, thomas@monjalon.net
References: <027ca076ea8e2be6bd76987da23298ffd5db550f.1605782511.git.anatoly.burakov@intel.com>
<20201119112431.GA1829@bricha3-MOBL.ger.corp.intel.com>
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Message-ID: <f98b6a01-2ca2-b2e8-71a9-335d70a33aa8@intel.com>
Date: Thu, 19 Nov 2020 11:44:06 +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: <20201119112431.GA1829@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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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 <anatoly.burakov@intel.com>
>> ---
>> 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 <bruce.richardson@intel.com>
>
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.
--
Thanks,
Anatoly