Possible enhancement: use ar M-scripts to create libmicroros.a

[gavanderhoorn]

The current implementation uses ar x to extract all objects from all .as in $TARGETDIR/install/lib, then ar rc to merge all objects into a single library again:

https://github.com/micro-ROS/micro_ros_setup/blob/a73f84707874b5a57852cab802d8d032610c3cbd/config/generate_lib/generic/build.sh#L40-L48

The ar documentation has a section on Controlling ar with a Script, which documents the M scripting language.

I've tested this to generate libmicroros.a with the following script (for my particular platform):

CREATE libmicroros.a
ADDLIB /.../install/lib/libactionlib_msgs__rosidl_generator_c.a
ADDLIB /.../install/lib/libactionlib_msgs__rosidl_typesupport_c.a
...
ADDLIB /.../install/lib/libyaml.a
SAVE
END

there is a small difference between the .a generated this way and the current implementation (the M-script version is about 7kB larger), but I've not run into linking issues.

The M-script is very easy to generate:

echo "CREATE libmicroros.a" > ar_script.m
for file in $(find "$FW_TARGETDIR/install/lib/" -name '*.a'); do
  echo "ADDLIB ${file}" >> ar_script.m
done
echo "SAVE" >> ar_script.m
echo "END" >> ar_script.m

and is very fast (approx 250ms on my system for 98 libraries).

There could be a potential downside to using it, which would be that ar appears to use a last-ADDLIB-wins approach when adding libraries with object files which have the same name.

I'm not sure how much of a problem that really is, as, looking at nm output, the library generated using the current approach prefixes objects with the package name, which would seem to prevent name-clashes, but would lead to a situation where there may be multiple versions of the same code/objects in the single .a. I'm not sure how the linker deals with that.

At least with M-scripts, this situation should not be possible.

---

Edit: it also helps on platforms/environments with a limit to the maximum command-line length. With many packages, the command-line passed to ar rc can become very long. The M-script circumvents this.

[pablogs9]

Good point @gavanderhoorn, could you please create a PR with the proposed solution?

[gavanderhoorn]

I've submitted #574.

[gavanderhoorn]

Closing as #574 was also closed.