Thanks Joao. That seems reasonable and makes sense to me.
From: Joao Alves Joao.Alves@arm.com Sent: Tuesday, February 16, 2021 8:37 AM To: Raghu K raghu.ncstate@icloud.com; Andrew Walbran qwandor@google.com Cc: hafnium@lists.trustedfirmware.org Subject: Re: [Hafnium] GN build system Question
Hi,
I've come across the same question when recently working on some patches for the Hafnium CI (https://review.trustedfirmware.org/c/hafnium/hafnium/+/7405).
I was trying to setup a standalone SP, trying to reuse most of what was available for a primary VM. I ended up taking the approach of defining a source_set specific to the standalone SP (https://review.trustedfirmware.org/c/hafnium/hafnium/+/7405/22/test/hftest/ BUILD.gn#129), extending only the public configurations. To build the SP, just defined a vm_kernel target referencing the newly defined source_set (https://review.trustedfirmware.org/c/hafnium/hafnium/+/7405/22/test/vmapi/f fa_secure_partition/BUILD.gn#11) in the target's dependencies.
The documentation for the source_set (https://gn.googlesource.com/gn/+/master/docs/reference.md#func_source_set) says: "In most cases, a source set will behave like a static library, except no actual library file will be produced.". Because of this, I thought of the source_set as "non-reconfigurable", therefore the above-described approach.
Someone could please comment, but my understanding is that this is the way to do it.
I hope this helps.
Best regards, João Alves
_____
From: Hafnium <hafnium-bounces@lists.trustedfirmware.org mailto:hafnium-bounces@lists.trustedfirmware.org > on behalf of Andrew Walbran via Hafnium <hafnium@lists.trustedfirmware.org mailto:hafnium@lists.trustedfirmware.org > Sent: Tuesday, February 16, 2021 4:20 PM To: Raghu K <raghu.ncstate@icloud.com mailto:raghu.ncstate@icloud.com > Cc: hafnium@lists.trustedfirmware.org mailto:hafnium@lists.trustedfirmware.org <hafnium@lists.trustedfirmware.org mailto:hafnium@lists.trustedfirmware.org > Subject: Re: [Hafnium] GN build system Question
I thought it would work to set the defines directly on the vm_kernel target, but apparently not. The only other way I can think of is to define a new toolchain, but that's probably worse than just making a copy of the source_set with the defines you want added. I'm not really a GN expert though.
On Tue, 16 Feb 2021 at 15:36, Raghu Krishnamurthy via Hafnium < hafnium@lists.trustedfirmware.org mailto:hafnium@lists.trustedfirmware.org
wrote:
Hi All,
I'm experimenting with a few things with hafnium tests and had a question of how(or what is the right way) to achieve the following with the GN build system.
I'm using the primary_with_secondaries test, to make a few modifications for an experiment. I want to be able to compile this test suite in such a way that the service_vm1 target(a vm_kernel target) is compiled with a different set(or additional set) of defines but not service_vm2 or service_vm3. I'm looking at the test/vmapi/primary_with_secondaries/services/BUILD.gn file for these targets. More concretely, I want service_vm1 to be compiled with -DFOO=1 in addition to existing defines and service_vm2/3 to be compiled without -DFOO=1.
I cant seem to find a way to force/push down extra defines on the source_sets referenced in the deps field at the vm_kernel("service_vm1") target. I know the other way(source_sets propagating their configs upwards to targets that depend on it through public_configs) is possible but I'd effectively like to do the reverse of it.
Should I just create another vm_kernel target, referencing all the source files directly(not existing source_sets) and having its own config? Or should I create new source sets with different configs? What is the GN way to achieve the above?
Thanks
Raghu
-- Hafnium mailing list Hafnium@lists.trustedfirmware.org
mailto:Hafnium@lists.trustedfirmware.org