That's weird, I haven't seen that before. Running either kokoro/build.sh or
'make checkpatch' locally works for me, whether or not CHECKPATCH is set.
The Makefile in the root directory is setting CHECKPATCH unconditionally,
but it looks like the one under drive/linux uses the existing value if
there is one. Maybe we should change that?
What error do you get when CHECKPATCH is not set?
On Fri, 15 May 2020 at 18:18, Olivier Deprez via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> Hi,
>
> Is there a known problem around checkpatch when running kokoro/build.sh
> locally?
>
> I noticed if CHECKPATCH env variable is already set then kokoro/build.sh
> fails with:
>
> + export CROSS_COMPILE=aarch64-linux-gnu-
> + CROSS_COMPILE=aarch64-linux-gnu-
> + cd driver/linux
> + make HAFNIUM_PATH=/home/olidep01/WORK/hafnium-upstream checkpatch
> <my-own-checkpatch-dir>/checkpatch.pl -f main.c
> Must be run from the top-level dir. of a kernel tree
> Makefile:43: recipe for target 'checkpatch' failed
> make: *** [checkpatch] Error 2
>
> If I unset CHECKPATCH before running build.sh then it fails at the
> driver/linux check.
>
> Is this something known and/or needing fix?
>
> Regards,
> Olivier.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> --
> Hafnium mailing list
> Hafnium(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/hafnium
>
Hi,
Is there a known problem around checkpatch when running kokoro/build.sh locally?
I noticed if CHECKPATCH env variable is already set then kokoro/build.sh fails with:
+ export CROSS_COMPILE=aarch64-linux-gnu-
+ CROSS_COMPILE=aarch64-linux-gnu-
+ cd driver/linux
+ make HAFNIUM_PATH=/home/olidep01/WORK/hafnium-upstream checkpatch
<my-own-checkpatch-dir>/checkpatch.pl -f main.c
Must be run from the top-level dir. of a kernel tree
Makefile:43: recipe for target 'checkpatch' failed
make: *** [checkpatch] Error 2
If I unset CHECKPATCH before running build.sh then it fails at the driver/linux check.
Is this something known and/or needing fix?
Regards,
Olivier.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Tue, 21 Apr 2020 at 21:18, Raghu K via Hafnium <
hafnium(a)lists.trustedfirmware.org> wrote:
> All,
>
> I was looking at the hafnium repositories on trusted firmware and was
> wondering how we envision managing the project on trustedfirmware.org vs
> googlesource. Is the plan to set up this project to be like
> googlesource, i.e using repo to manage the multiple repositories ? There
> appears to be dependencies on third party tools/prebuilts in the
> BUILD.gn files so using something like repo even on trustedfirmware.org
> sounds useful.
>
The plan is to continue using git submodules for this. The main Hafnium
repository has submodules for:
prebuilts
driver/linux
project/reference
third_party/dtc
third_party/googletest
third_party/linux
The .gitmodules file currently still points to the old URLs but this will
be updated once the migration is complete. (We are currently blocked on
getting CI running on the new infrastructure.) The advantage of submodules
over repo for this is that it ties specific versions together, which is
important for bisection or otherwise checking out old versions to work
properly. Often we make changes in one repository which need to happen at
the same time as a change in another repository for the build to work. Repo
doesn't provide a way to link versions together like this. We were using
repo for some internal Google tools which don't support submodules, but
this shouldn't be necessary anymore.
Hi Raghu,
The transition of repo, CI and tools is still taking place, we can expect in the shorter term the project management to be very similar although on TF.org servers to what it was previously but longer term tighter integration with TF-A will occur but details are still being worked out. We expect a TF-A Tech Forum meeting in the near term future to cover more details of Hafnium integration and other subjects.
Thanks
Joanna
On 21/04/2020, 21:19, "Hafnium on behalf of Raghu K via Hafnium" <hafnium-bounces(a)lists.trustedfirmware.org on behalf of hafnium(a)lists.trustedfirmware.org> wrote:
All,
I was looking at the hafnium repositories on trusted firmware and was
wondering how we envision managing the project on trustedfirmware.org vs
googlesource. Is the plan to set up this project to be like
googlesource, i.e using repo to manage the multiple repositories ? There
appears to be dependencies on third party tools/prebuilts in the
BUILD.gn files so using something like repo even on trustedfirmware.org
sounds useful.
Thanks
Raghu
--
Hafnium mailing list
Hafnium(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/hafnium
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
All,
I was looking at the hafnium repositories on trusted firmware and was
wondering how we envision managing the project on trustedfirmware.org vs
googlesource. Is the plan to set up this project to be like
googlesource, i.e using repo to manage the multiple repositories ? There
appears to be dependencies on third party tools/prebuilts in the
BUILD.gn files so using something like repo even on trustedfirmware.org
sounds useful.
Thanks
Raghu
