From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50372C3DA7D for ; Wed, 4 Jan 2023 00:25:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238221AbjADAZY (ORCPT ); Tue, 3 Jan 2023 19:25:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35838 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238538AbjADAZN (ORCPT ); Tue, 3 Jan 2023 19:25:13 -0500 Received: from ms.lwn.net (ms.lwn.net [45.79.88.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A50E17072; Tue, 3 Jan 2023 16:25:10 -0800 (PST) Received: from localhost (unknown [IPv6:2601:281:8300:73::5f6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ms.lwn.net (Postfix) with ESMTPSA id E0BF94BF; Wed, 4 Jan 2023 00:25:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 ms.lwn.net E0BF94BF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lwn.net; s=20201203; t=1672791910; bh=S3spks9Z3wmS5gxYl1y0L64CJtVZjwQ9VVkqSNfKJcY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=rMJ28Ezh6hVPz4pqbvWt/cRGjev4V/e1ApD+kqTclK6+wfPPXmeI79ArQTtFY/zUD tY9T5ICDW57fs9/ERtWFvTMcgcY0EW3jJ1U8EMI7In7uQzzg+rI/9qUe2eSFeo7R0H mSiZrffgtILUlLR4rRLQfKaUDV7zBbreSbwzauUK2DmlSiyT61+iAiVG8Covd6YEjm kGV+5z7UjSOOJrCpZf7NvxzMXoHd4ILJ6Zv+ceFd2ciaLsckWbhRoTXj3UBASivXfn Fetk6h9QLaikn8xLRFqd31dfyWnpAtXSE3ndWHVa5R6+6lfWJv/73Fao5YyNLLiQRK t4CCvJjB7r7zg== From: Jonathan Corbet To: Miguel Ojeda Cc: Carlos Bilbao , ojeda@kernel.org, akiyks@gmail.com, jani.nikula@linux.intel.com, rdunlap@infradead.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, konstantin@linuxfoundation.org Subject: Re: [PATCH v5 0/2] docs: Integrate rustdoc into Rust documentation In-Reply-To: References: <20221207173053.1463800-1-carlos.bilbao@amd.com> <20221228174623.144199-1-carlos.bilbao@amd.com> <87wn64fq7d.fsf@meer.lwn.net> Date: Tue, 03 Jan 2023 17:25:09 -0700 Message-ID: <87h6x7cfiy.fsf@meer.lwn.net> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Miguel Ojeda writes: >> - It did a bunch of other building, starting with objtool - again, never >> needed for the docs build before. > > Yeah, rustdoc, like the compiler, requires dependencies to be > available to understand the code. Thus some things need to be > compiled, like for the normal build. Does it really need objtool? A certain amount of extra building is OK as long as it doesn't radically slow down the (already glacial) docs build. I'd like it to not *break* the docs build if the right dependencies aren't there, though. >> version is really supported, but it would be nice to fail a bit more >> gracefully if at all possible. > > Do you mean failing in the `scripts/rust_is_available.sh` step instead > of warning? We could also add versioning information to that script, > so that it knows more about which versions work etc., but I guess at > that point it would be best to simply start supporting several > versions, which may be a bit too early to split CI runs on that since > it would require some degree of testing. It seems like that step should fail regardless, not just for the docs build, no? Otherwise, though, it would suffice to turn a failure to build the Rust docs into a warning-level event for the docs build; I'm mostly concerned about it breaking the build as a whole. Supporting multiple Rust versions would be nice, but it's up to you to decide when you think you can do that; I don't think the docs build should drive it. Thanks, jon