Hello Bob and Liming,

Liming:
> Order may not resolve the problem. Build tool needs to know their 
> relationship, and generate the correct dependency between ASL and C source 
> file.
> If there is no dependency between them in Makefile, Makefile multiple thread 
> build (make -jn) may break it.

I agree. The patch I sent is just re-ordering the files in the "CODA_TARGET" 
makfefile target, putting the '.aml' file before the '.c' file. The outcome is 
as below in the generated Makefile:
CODA_TARGET = [AbsolutePathTo]\OUTPUT\SsdtSerialTemplate.aml \
                               [AbsolutePathTo]\OUTPUT\AcpiSsdtSerialLibArm.lib 
\

For a multiple thread build, the dependency would not be respected. The patch I 
sent cannot work.

Bob:
> I meet another problem related to .asl file. In one of platforms build 
> process, there is a step which need to compile a .asl file a .h file firstly 
> and that .h file will be included by a module’s source code.
> That step cannot be handled in edk2 build since the compilation command use 
> different build option, so it’s done in a pre-build script. I want to make 
> edk2 build be able to handle such case. So
> together with your case,  I think we may need a solution that can do:
> 1.       Create a module which contains the .asl file and the build option to 
> compile that .asl file.
> 2.       Find a way to describe the dependency relation between the module 
> contains .asl and the corresponding module contains .c file

We have tested the solution you suggested and the build is working. We split 
our module in two modules:
* a first one containing the '.asl' files to compile. It looks like:
[Sources]
   SsdtSerialTemplate.asl

* a second one containing the '.c' and '.h' files. It resolves the dependency 
on the generated '.hex' file via the 'TemplateLibClass' library class. It looks 
like:
AcpiSsdtSerialLibArm.inf:
  [Sources]
    SourceFile1.h
    SourceFile1.c
    SourceFile2.h
    SourceFile2.c
  [LibraryClasses]
    TemplateLibClass
  [BuildOptions]
    *_*_*_PLATFORM_FLAGS = -I$(OUTPUT_DIR)
    *_*_*_PLATFORM_FLAGS = -I$(OUTPUT_DIR)$(MODULE_RELATIVE_DIR)Template/OUTPUT

Our '.dsc' file build both modules like:
DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtSerialLibArm/AcpiSsdtSerialLibArm.inf
TemplateLibClass|DynamicTablesPkg/Library/Acpi/Arm/AcpiSsdtSerialLibArm/Template.inf

This solution is working. However we have to create two modules for one single 
feature. Thus we need to include output files from two modules. These modules 
need to be correctly configured to make the build work, which I feel is not 
straightforward.
You say you have a similar issue. Having a more intuitive and standard solution 
to impose a build order within a module would potentially help other people. It 
would also simplify their build configuration. I think having a new 
[SourceOrder] section in '.inf' files could avoid us to do this.
We just need to create an intermediate target in the Makefile for the 
CODA_TARGET target. For instance, for the following order in a '.inf' file:
[SourceOrder]
  .c        # Build '.c' files first
  .asl      # Build '.asl' second

This would create the following Makefile tagets:
# CODA_TARGET needs to build FIRST_TARGET, SECOND_TARGET and UNORDERED_TARGET.
# We create as many targets as the number of elements in the [SourceOrder] 
section.
CODA_TARGET = $(FIRST_TARGET) $(SECOND_TARGET) $(UNORDERED_TARGET)

# Build SECOND_TARGET before UNORDERED_TARGET
UNORDERED_TARGET: SECOND_TARGET
# Build FIRST_TARGET before SECOND_TARGET
SECOND_TARGET: FIRST_TARGET

# Build the .aml first, then the .c files, then the unordered files (none here).
FIRST_TARGET = $(OUTPUT_DIR)\SsdtSerialTemplate.aml
SECOND_TARGET = $(OUTPUT_DIR)\AcpiSsdtSerialLibArm.lib
UNORDERED_TARGET =

Again, I am ok to write a prototype if this solution is acceptable to you.

Regards,
Pierre

From: Feng, Bob C <bob.c.f...@intel.com>
Sent: 13 November 2019 01:40
To: devel@edk2.groups.io; Pierre Gondois <pierre.gond...@arm.com>; Gao, Liming 
<liming....@intel.com>; nd <n...@arm.com>
Cc: Sami Mujawar <sami.muja...@arm.com>
Subject: RE: [edk2-devel] [PATCH v1 1/1] BaseTools: Build ASL files before C 
files

Hi Pierre,

I meet another problem related to .asl file. In one of platforms build process, 
there is a step which need to compile a .asl file a .h file firstly and that .h 
file will be included by a module’s source code. That step cannot be handled in 
edk2 build since the compilation command use different build option, so it’s 
done in a pre-build script. I want to make edk2 build be able to handle such 
case. So together with your case,  I think we may need a solution that can do:

  1.  Create a module which contains the .asl file and the build option to 
compile that .asl file.
  2.  Find a way to describe the dependency relation between the module 
contains .asl and the corresponding module contains .c file

Thanks,
Bob

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
[mailto:devel@edk2.groups.io] On Behalf Of PierreGondois
Sent: Tuesday, November 12, 2019 9:34 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Feng, Bob C 
<bob.c.f...@intel.com<mailto:bob.c.f...@intel.com>>; Gao, Liming 
<liming....@intel.com<mailto:liming....@intel.com>>; nd 
<n...@arm.com<mailto:n...@arm.com>>
Cc: Sami Mujawar <sami.muja...@arm.com<mailto:sami.muja...@arm.com>>
Subject: Re: [edk2-devel] [PATCH v1 1/1] BaseTools: Build ASL files before C 
files

Hello Bob and Liming,
Do you think the solution suggested earlier could be acceptable? I refer to the 
solution below, i.e. having a new section in the ‘.inf’ files describing an 
extension build order.
E.g.:
  [SourceOrder]
    asl
    c
In this example, ‘.asl’ files would be built first, then ‘.c’ files, then any 
other files present in the modules. Among ‘.asl’ files, the order would be 
preserved. Same among ‘.c’ files.

If this solution suits you, we can begin to do a first implementation.

Regards,
Pierre

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
<devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Bob Feng via 
Groups.Io
Sent: 04 November 2019 07:50
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Pierre Gondois 
<pierre.gond...@arm.com<mailto:pierre.gond...@arm.com>>; Gao, Liming 
<liming....@intel.com<mailto:liming....@intel.com>>
Subject: Re: [edk2-devel] [PATCH v1 1/1] BaseTools: Build ASL files before C 
files

Hi Pierre,

How do you compile 'SsdtSerialPortTemplate.asl' with the '-tc' to the .HEX 
file? , based on the build_rule.txt, I think the .asl output file is a .aml 
file.

[Acpi-Source-Language-File]
    <InputFile>
        ?.asl, ?.Asl, ?.ASL

    <OutputFile>
        $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.aml

Thanks,
Bob

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
[mailto:devel@edk2.groups.io] On Behalf Of PierreGondois
Sent: Thursday, October 31, 2019 7:12 PM
To: Gao; Gao, Liming <liming....@intel.com<mailto:liming....@intel.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: Re: [edk2-devel] [PATCH v1 1/1] BaseTools: Build ASL files before C 
files

Hello Liming,
Please find my answers marked [PIERRE] inline.

>> Can you give the whole solution for this usage model?
[Pierre]
We are planning to modify specific values in pre-compiled AML definition blocks 
at run-time, and then install these AML definition blocks as SSDT tables.
Instead of having multiple ASL describing the same kind of device (e.g.: a 
serial port), we would have one template describing this kind of device (e.g.: 
an ASL description of a serial port).
This template would be generic for the type of device it is describing, and 
compiled as one standalone AML definition block.
Platform specific values of this template would then be modified at run-time.

>> Does it mean C source file depends on ASL file?
[Pierre]
Yes. To do this, we need to embed these pre-compiled AML definition blocks. The 
.c file doing the fix-up needs to include this template. Thus this template 
needs to be compiled first.

The '.inf' file responsible of the fix-up looks like:
[SOURCES]
  SsdtSerialPortTemplate.asl
  SerialPortFixup.c

Compilation of 'SsdtSerialPortTemplate.asl' with the '-tc' option outputs a 
'SsdtSerialPortTemplate.hex' file. '.hex' file's content looks like:
unsigned char ssdtserialtemplate_aml_code[] =
{
    0x53,0x53,0x44,0x54,0xC8,0x00,0x00,0x00,  /* 00000000    "SSDT...." */
    ...
}

The 'SerialPortFixup.c' includes the '.hex' file as shown below:
#include "SsdtSerialPortTemplate.hex"

>> This is related to the priority of source file type.
[Pierre]
Yes, the 'SsdtSerialPortTemplate.asl' needs to be compiled (so that the 
'SsdtSerialPortTemplate.hex' is generated) prior to the compilation of 
'SerialPortFixup.c'.

>> Now, there is no method to let user configure them. I suggest to introduce 
>> the generic way instead of the specific handle.
[Pierre]
I agree that we should have a generic way to configure the order in which the 
files should be compiled.
A new "SourceOrder" section could be introduced. This section would describe 
file extensions to compile first, and their order. Unreferenced file extensions 
would be compiled at the end, unordered.
e.g.:
  [SourceOrder]
    asl
    c

Here, '.asl' files would be compiled first, then '.c' files. '.asl' files would 
remain unordered in among all '.asl' files. '.c' files would remain unordered 
in among all '.c' files. Any remaining files in the "Sources" section would be 
compiled at the end, unordered.

Regards,
Pierre
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.

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.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#50726): https://edk2.groups.io/g/devel/message/50726
Mute This Topic: https://groups.io/mt/39786201/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to