That wasn’t my exact thought but that could work as well.. The idea is to implement full preprocessor support in iASL so that we wouldn’t need to use trim and iASL for ASL pre-processing/compilation and just use iASL. Along the way, we might be able to support what you mentioned as well. From: Gao, Liming Sent: Monday, April 8, 2019 9:23 AM To: devel@edk2.groups.io; Schmauss, Erik ; felixp@ami.com Subject: RE: [edk2-devel] ASL build tools - EDKII trim tool questions Do you mean that iASL compiler will support the preprocessor line style in the preprocessed ASL file, such as #line 50 "d:\allpkg\edk2\TestPkg\TestAsl\Test.asi"? If so, iASL compiler can report the accurate error line number in original source file. Thanks Liming From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Schmauss, Erik Sent: Friday, April 5, 2019 7:44 AM To: devel@edk2.groups.io; felixp@ami.com Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions Hi Felix, Thanks for the info! I am not a firmware developer by any means. However, it seems difficult to develop code in an environment where compiler error line numbers do not match the actual source… I’ve heard several people complain about this and I would like to help alleviate these pain-points if possible (and practical). Hypothetically, if iASL had support for a preprocessor that produced the exact same ASL/AML output as the current toolchain, would there be interest in switching build system over to solely use edkii? From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Felix Polyudov Sent: Thursday, April 4, 2019 3:11 PM To: devel@edk2.groups.io; Schmauss, Erik > Subject: Re: [edk2-devel] ASL build tools - EDKII trim tool questions Eric, One of the reasons the trim tool is used is to support usage of C macros in ASL files (ASL files may include C header files and are processed by a C preprocessor). This is edk2 way of reusing the same constant definition across source files in different formats. From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of erik.schmauss@intel.com Sent: Thursday, April 04, 2019 3:08 PM To: devel@edk2.groups.io Subject: [edk2-devel] ASL build tools - EDKII trim tool questions Hello, I work on the ACPICA project (iASL, acpidump, acpiexec, and etc). I’ve been looking at the EDKII repository and tools that relate to ACPI and ASL. In particular, I’ve been looking at the trim tool https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/Trim/Trim.py According to the source code, the “--asl-file” option replaces #include and Include (a.k.a. the “ASL include”) with actual contents of the file. I would prefer everyone to use iASL compiler to do this instead. The problem with trim is that it makes iASL compiler errors more difficult to understand because the original file has been preprocessed by trim and the line numbers from iASL remarks/warnings/errors do not make sense to the programmer... The iASL compiler handles ASL include statements as well as preprocessor #include statements. When compiling these files with include statements/directives, iASL displays the correct line number and file name of the included file. Therefore, I think it would be beneficial to developers to use only iASL rather than trim "--asl-files" and iASL to work on ASL files. I've been talking to some people internally about this trim tool but I would like to ask this community if anyone has thoughts/opinions on deprecating trim's ASL option. Thanks, Erik P Please consider the environment before printing this email The information contained in this message may be confidential and proprietary to American Megatrends, Inc. This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.