nuttx/pass1
Alan Carvalho de Assis c027e7c3e4 tools: fix stale archive members surviving a Kconfig-driven CSRCS change
During the Toybox port to NuttX, Claude noticed that changes in the
menuconfig weren't taking affect. This issue exists for a long time on
NuttX, in fact BayLibre's presentation from 2017 make jokes about our
building system not been reliable:
https://www.youtube.com/watch?v=XUJK2htXxKw&t=320s

Stale archive members from $(AR)'s additive-only behavior can linger
after Kconfig toggles change which files provide a symbol, causing dead
weight or "multiple definition" link errors on incremental builds.
Fixed by splitting ARCHIVE into two macros: ARCHIVE keeps the original
additive behavior for apps/libapps.a, which many independent
subdirectories contribute to across a build, while the new
ARCHIVE_REBUILD deletes then archives for the far more common case
of a single Makefile building its own self-contained $(OBJS)
- all 39 such call sites now use it.

Assisted-By: Claude Sonnet 5
Signed-off-by: Alan C. Assis <acassis@gmail.com>
2026-07-28 21:26:03 -03:00
..
.gitignore build: Remve the unnecessary .gitignore 2020-05-23 18:00:40 +01:00
Makefile tools: fix stale archive members surviving a Kconfig-driven CSRCS change 2026-07-28 21:26:03 -03:00
README.txt Beginning to update comments to reflect new organization of the boards/ sub-directory. 2019-08-08 08:46:54 -06:00

README
======

  This directory provides support for the two-pass build.  Its primary
  purpose is to incorporate source logic generated by applications into the
  kernel phase of the build.

  In the two pass build, the application logic is built during the first
  phase, pass 1.  In that phase, the application may generate and install
  source files into the pass1/ directory.

  The operating system is built during phase 2 of the build.  At that time,
  those source files in the pass1/ directory will be built and incorporated
  into the kernel address space.

  The primary purpose of the pass1/ directory is to such application-
  generated kernel symbol tables.  For an example of the use of this
  feature, look at apps/examples/module/drivers/Makefile.  Kernel symbol
  tables are needed to support kernel modules.

  Of course, addition board-specific logic in, say, at
  boards/<arch>/<chip>/<board>/src would have to be included to make use of
  the application-installed symbol tables.