hartmannathan commented on PR #17236:
URL: https://github.com/apache/nuttx/pull/17236#issuecomment-3448793007
> @TangMeng12 Please look here #13301
>
> The idea behind this logic was to reduce the time needed for the jobs.
>
> With the change you want to make, build times on CI will be longer than
before.
Throughout NuttX, and mostly in the `nuttx-apps` repo, there are various
optional components that might be downloaded.
I think we need to discuss (on the mailing list) and come up with a
systematic approach that balances everyone's needs in a suitable way.
Some of those needs are:
- In Kconfig, there should be one permission config "Allow downloads", help
text: "Allow the NuttX build system to automatically download external packages
from the Internet." Suggested name: `CONFIG_ALLOW_DOWNLOADS`. In the build
system, downloading will occur through one central function that may call wget,
curl, git, or other commands as needed, and that function will return an error
if `CONFIG_ALLOW_DOWNLOADS` is not configured, aborting the build. This is
important because some developers will want to ensure there are no automatic
downloads. If external packages are needed, those developers will need to
provide them manually.
- Some developers may allow downloads in general, but will prefer to
download some individual package manually. This allows developers to add their
own customizations, choose alternate versions, alternate branches, etc. ("Out
of tree downloads.") To support this, each package should have its own
fine-grained permission Kconfig to enable or disable downloading that package
from the internet.
- Some developers will prefer to store external packages at custom path on
their workstation. To support this, each package needs a Kconfig to provide the
custom path on the developer's workstation. This can be combined with the
previous item.
- Some developers will prefer to allow downloads, but customize the URLs.
This way, they can control which server the download will come from. The server
could be a local server on their own intranet or perhaps a custom fork on the
internet. To support this, each package needs a Kconfig to specify the URL.
- The CI system needs to utilize its resources in a smart way, as pointed
out by @simbit18 above. So we need a Kconfig to select between downloading the
release tarballs or cloning the repository.
Rather than maintaining a hodgepodge of different approaches, a systematic
approach will make it easier to add new external dependencies, maintain
existing ones, and handle licensing correctly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
