[gn] Simplify Support::CHIPMem build.

[turon]

Problem

When a source file is wrapped internally to only activate when the proper configuration macros are passed, then we can simplify the build to just include all files.

Summary of Changes

Perform such a simplification for support/CHIPMem

[rwalker-apple]

lgtm

[andy31415]

At some point we should pull out the #ifdefs from the alloc cpp files (after autotools is changed).

[andy31415]

I actually read the patch in reverse: why do we want to compile the files and rely on #ifdef macros to include or not functions inside the alloc. This looks backwards to me - we should fix autotools instead.

[andy31415]

I actually read the patch in reverse: why do we want to compile the files and rely on #ifdef macros to include or not functions inside the alloc. This looks backwards to me - we should fix autotools instead.

I will leave it to @mspang about best practices, but this seems backwards to me - if I see 'foo.cpp' being compiled, I assume it has useful code. if foo.cpp contains a '#ifdef FOO_ENABLED...' and then I compile and get nothing, that is very confusing.

[mspang]

It causes a warning on Mac if we build a static library containing a file with no symbols.

[mspang]

It causes a warning on Mac if we build a static library containing a file with no symbols.

Chrome has a wrapper for Mac's libtool to suppress these warnings, so another solution is to adopt such a wrapper to suppress the warning.

[mspang]

Marking request changes. We should have some way to avoid the warning.

[andy31415]

Created #1595 to figure out some way to to standardize things or get a decision if the #ifdef pattern is a pattern we want to stick with.

Generally the pattern is alien to me (I expect that I only compile what I need and if I compile something, that something is generating output), however if this is somehow standard across many libraries I can live with it. Marking approve on this one for now.

[turon]

I actually read the patch in reverse: why do we want to compile the files and rely on #ifdef macros to include or not functions inside the alloc. This looks backwards to me - we should fix autotools instead.

@andy31415 Thanks for opening #1595. @mspang I agree we need a workaround for empty file warnings on Mac -- any ideas on how to do that?

I'm not super opinionated on small adjustments like this, but I can say that large systems such as CHIP tend to have many ways to pass configuration:

1. through the build system (thus building hard dependencies and maintenance requirements on those build systems that are supported)
2. through C defines and config.h headers
3. both

In order to better decouple the codebase from any particular build system, OpenThread as a project had agreed upon and moved to a model where most configuration was passed via (2). This PR is exploiting the fact that (2) is in place already for CHIPMem, and therefor decoupling that config from GN. For consistency, the PR should probably make the parallel updates to autotools as well.

[github-actions]

Size increase report for "nrf-example-build"

File	Section	File	VM
chip-nrf52840-lock-example.out	.text	193692	193692
chip-nrf52840-lock-example.out	.data	-32	-32
chip-nrf52840-lock-example.out	.bss	0	-4572

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-nrf52840-lock-example.out and ./pull_artifact/chip-nrf52840-lock-example.out:

sections,vmsize,filesize
.text,193692,193692
.debug_loc,0,88741
.strtab,0,76213
.debug_info,0,45293
.symtab,0,15888
[Unmapped],0,2916
.data,-32,-32
.debug_macro,0,-272
.bss,-4572,0
.debug_abbrev,0,-8251
.debug_aranges,0,-24224
.debug_ranges,0,-29944
.debug_line,0,-48999
.debug_frame,0,-62024
.debug_str,0,-191229

[github-actions]

Size increase report for "linux-example-build"

File	Section	File	VM

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-standalone-demo.out and ./pull_artifact/chip-standalone-demo.out:

sections,vmsize,filesize

[github-actions]

Size increase report for "esp32-example-build"

File	Section	File	VM

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

Comparing ./master_artifact/chip-wifi-echo.elf and ./pull_artifact/chip-wifi-echo.elf:

sections,vmsize,filesize

[github-actions]

Size increase report for "gn_nrf-example-build"

File	Section	File	VM

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

[github-actions]

Size increase report for "gn_linux-example-build"

File	Section	File	VM

Full report output

BLOAT REPORT

Files found only in the build output:
    report.csv

[mspang]

I actually read the patch in reverse: why do we want to compile the files and rely on #ifdef macros to include or not functions inside the alloc. This looks backwards to me - we should fix autotools instead.

@andy31415 Thanks for opening #1595. @mspang I agree we need a workaround for empty file warnings on Mac -- any ideas on how to do that?

Three ideas

1. Wrap libtool with a script that filters out uninteresting warnings. Chrome does this.
2. Do nothing? No warning if we conditionally compile the file.
3. (hacky) Add some unused symbol to the file.

I'm not super opinionated on small adjustments like this, but I can say that large systems such as CHIP tend to have many ways to pass configuration:

1. through the build system (thus building hard dependencies and maintenance requirements on those build systems that are supported)
2. through C defines and config.h headers
3. both

In order to better decouple the codebase from any particular build system, OpenThread as a project had agreed upon and moved to a model where most configuration was passed via (2). This PR is exploiting the fact that (2) is in place already for CHIPMem, and therefor decoupling that config from GN. For consistency, the PR should probably make the parallel updates to autotools as well.

[woody-apple]

@andy31415 @mspang next steps?

[mspang]

@andy31415 @mspang next steps?

I would like to hold the line on avoiding uninteresting build output as this can drown out useful information. Here is the script Chrome uses to squelch uninteresting libtool warnings on Mac:

https://chromium.googlesource.com/chromium/src.git/+/master/build/toolchain/mac/filter_libtool.py

[woody-apple]

@turon Can we address @mspang 's feedback here?

[turon]

Closing until more general mechanisms for handling empty file warnings are in place.