going Posted September 29, 2018 Posted September 29, 2018 1. What is the purpose when compilation errors are sent to a common output and then branched to a file? It turns out a million lines. It is reasonable to have only compiler error messages. 2. What is the purpose when the kernel-source package is built with include the folder /.git/? It is not traditional 3. Why folder with sources not cleared fully before compilation? git commands: git reset --hard HEAD; git clean -df guarantee a clean sheet before starting work
going Posted October 1, 2018 Author Posted October 1, 2018 For me, these three points are a big problem. If the founding fathers and users feel similar, I can provide a patch that fixes these issues. 1
chwe Posted October 2, 2018 Posted October 2, 2018 On 10/1/2018 at 9:45 AM, going said: If the founding fathers and users feel similar, I can provide a patch that fixes these issues. as discussed here: if you have proper patch for it I suggest you prepare a PR. It might get more attention if it shows up on github (it's likely that your findings were during the large update to 5.60 and got lost during this time). Maybe start with: On 9/29/2018 at 1:40 PM, going said: 3. Why folder with sources not cleared fully before compilation? git commands: git reset --hard HEAD; git clean -df guarantee a clean sheet before starting work Edit: https://docs.armbian.com/Process_Contribute/ might be worth to read as well.
going Posted October 5, 2018 Author Posted October 5, 2018 On 10/2/2018 at 4:08 PM, chwe said: Edit: https://docs.armbian.com/Process_Contribute/ might be worth to read as well. " Cleaning methods and options: CLEAN_LEVEL (comma-separated list): defines what should be cleaned. Default value is "make,debs" - clean sources and remove all packages. Changing this option can be useful when rebuilding images or building more than one image “make” = execute make clean for selected kernel and u-boot sources, “images” = delete output/images (complete OS images), “debs” = delete packages in output/debs for current branch and device family, “alldebs” = delete all packages in output/debs, “cache” = delete cache/rootfs (rootfs cache), “sources” = delete cache/sources (all downloaded sources), “extras” = delete additional packages for current release in output/debs/extra " Options for wrong actions: Forgot, inattentive, syntax error. There is no desire to pull all sources when the goal is to add or remove support for a single kernel driver or module. But, in any case, the Assembly script works, we must ensure the purity of the source that every time you start with a clean slate. This is a very important point. I am trying to handle possible user errors and negative work options. I have studied this document well: https://docs.armbian.com/Process_Contribute/ And translated it into his native language. P.S. Build system armbian works very well. I want it to be the perfect tool.
chwe Posted October 5, 2018 Posted October 5, 2018 30 minutes ago, going said: P.S. Build system armbian works very well. I want it to be the perfect tool. Nothing is perfect. And if you find something to enhance, pull requests are welcomed here! I think the 'cleanlevel' really is an issue especially for limited bandwidth and also during patch creation. So fork it, create a features branch and send a PR against Armbian master. P.S. I edited your topic name, I don't think the questions are stupid.
going Posted October 5, 2018 Author Posted October 5, 2018 35 minutes ago, chwe said: P.S. I edited your topic name, I don't think the questions are stupid. Thanks. It turned out two topics on one big question: How to do better? I will prepare an explanatory note and patch, or as you said: 55 minutes ago, chwe said: create a features branch and send a PR against Armbian master. I think then the two topics can be combined. 1
chwe Posted October 5, 2018 Posted October 5, 2018 5 minutes ago, going said: I will prepare an explanatory note and patch, 5 minutes ago, going said: I think then the two topics can be combined. Do it as you think it's best and if it turns out that it isn't perfect, the PR can still be edited before it gets merged. I would link to those two threads when sending the PR, so that a reviewer know where it comes from. 1
Recommended Posts