Leverage forward declarations to improve compile times

[Levi-Armstrong]

This cuts the build time from 4 minutes and 30 seconds to 2 minutes and 45 seconds.

[marip8]

Are the fwd.h headers not problematic by declaring a bunch of classes that don't necessarily get used in each source file? Why not just declare the specific classes that each header needs to reference?

[Levi-Armstrong]

Are the fwd.h headers not problematic by declaring a bunch of classes that don't necessarily get used in each source file?

It is not because you can declare things as many time as you want but you can only have one define it once.

Why not just declare the specific classes that each header needs to reference?

Because forward declaration can be problematic especially when using in template classes, so it is encouraged that developers provide this file to let users know what types are okay to use as forward declarations. An example of this is the #include <iosfwd> provided by the standard libraries to avoid having IO headers in your headers.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.17%. Comparing base (d361f7d) to head (fccd356).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #990      +/-   ##
==========================================
- Coverage   90.91%   90.17%   -0.74%     
==========================================
  Files         280      280              
  Lines       15876    15701     -175     
==========================================
- Hits        14434    14159     -275     
- Misses       1442     1542     +100     

see 181 files with indirect coverage changes

[Levi-Armstrong]

@johnwason Would you have time to look into what the issue is with the windows test failures?

[johnwason]

Why not just use precompiled headers instead of reworking everything?

[Levi-Armstrong]

Why not just use precompiled headers instead of reworking everything?

At this point I am almost finished updating everything.

[johnwason]

@Levi-Armstrong my fixes didn't work... go ahead and force push to revert my last two commits.

[johnwason]

I am not seeing the serialization unit test failures locally. I am seeing issues with the static loader plugin tests.

[Levi-Armstrong]

@johnwason This may be related.

[johnwason]

I am not seeing the serialization unit tests locally. I am investigating but so far don't have an explanation. Maybe try clearing the github action cache completely?

[Levi-Armstrong]

Can I manually clear the cache?

[johnwason]

You can see all the caches here: https://github.com/tesseract-robotics/tesseract/actions/caches

Not sure how to "clear all" though

[johnwason]

I updated to the newest vcpkg boost version and now I am seeing the test failures. I will keep trying to trace the error.

[johnwason]

Looking at the CI, the Conda Windows CI is working with Boost 1.82, while the vcpkg Windows build is failing with Boost 1.84. This may be a problem with Boost 1.84.

[johnwason]

Yeah I am seeing the same failures on the scheduled builds on master. This looks like a boost problem.

[johnwason]

I ran a matrix build of different boost versions, and only 1.84 is failing. https://github.com/johnwason/tesseract/actions/runs/8242279639/job/22540993793

I set the vcpkg revision to use boost 1.83. I recommend opening an issue with boost serialization.

[Levi-Armstrong]

@johnwason I believe I removed your change when I force pushed. What change do I need to make to pin the version?

[johnwason]

@Levi-Armstrong I pushed the commit

[johnwason]

See boost/serialization issue boostorg/serialization#309