Descent3 icon indicating copy to clipboard operation
Descent3 copied to clipboard

Kill unused srcs

Open tophyr opened this issue 1 year ago • 11 comments
trafficstars

Remove a bunch of unused-code cruft.

Test Plan: On all three of [win, mac, linux]:

cmake --preset <platform>
cmake --build --preset <platform> --config Debug
cmake --build --preset <platform> --config Release

tophyr avatar Apr 26 '24 08:04 tophyr

Please do not remove the legacy folder, it is there for a reason. File endings do not need to change either (or at least in a separate PR)

Lgt2x avatar Apr 26 '24 08:04 Lgt2x

I did wonder about that. Will fix tomorrow.

On Fri, Apr 26, 2024 at 3:12 AM Louis Gombert @.***> wrote:

Please do not remove the legacy folder, it is there for a reason. File endings do not need to change either (or at least in a separate PR)

— Reply to this email directly, view it on GitHub https://github.com/DescentDevelopers/Descent3/pull/188#issuecomment-2078868957, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPB6RJGYTWTCLXDUMSU4Y3Y7ID7LAVCNFSM6AAAAABG2KBFDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZYHA3DQOJVG4 . You are receiving this because you authored the thread.Message ID: @.***>

tophyr avatar Apr 26 '24 08:04 tophyr

How has this been verified as unused? You have things that at first glance look very used, like the renderer folder.

JeodC avatar Apr 26 '24 10:04 JeodC

Didn't see whole changeset, but there mostly old Mac OS 9 code (#ifdef MACINTOSH) and files that not included to CMakeLists.txt files.

winterheart avatar Apr 26 '24 10:04 winterheart

The first commit uses unifdef to remove any MACINTOSH-dependent preprocessor blocks, and the second commit does some string parsing on on CMakeLists.txt files to find all files that are are referenced, and then deletes any *.c(pp)? that isn't part of that list.

Builds were performed (but resulting binaries not tested beyond that) on all of Linux, Mac and Windows for each commit.

Finally, legacy/ was manually restored in each commit per @Lgt2x's advice.

tophyr avatar Apr 26 '24 17:04 tophyr

The first commit uses unifdef to remove any MACINTOSH-dependent preprocessor blocks, and the second commit does some string parsing on on CMakeLists.txt files to find all files that are are referenced, and then deletes any *.c(pp)? that isn't part of that list.

Builds were performed (but resulting binaries not tested beyond that) on all of Linux, Mac and Windows for each commit.

Finally, legacy/ was manually restored in each commit per @Lgt2x's advice.

Thanks for that explanation. 👍

JeodC avatar Apr 26 '24 17:04 JeodC

am updating commits with process for posterity, don't merge yet

tophyr avatar Apr 26 '24 17:04 tophyr

One request I want to make, the files in the renderer dir "Direct3D.cpp", "renderer.cpp", and "opengl.cpp" should be moved to a new renderer dir in the legacy dir, since these are potentially important for reference, since the different renderers have different features.

InsanityBringer avatar Apr 26 '24 18:04 InsanityBringer

@InsanityBringer will do!

tophyr avatar Apr 26 '24 19:04 tophyr

Ok, each commit now has the process used to generate it ("Delete unused srcs" is a doozy) and the commits are better broken apart to show the steps. The renderer files @InsanityBringer requested are moved to legacy/ for preservation.

tophyr avatar Apr 26 '24 22:04 tophyr

tophyr ran his script in jmarshall's fork (the one improving the dev editor) and confirmed there are no editor dependencies removed in the script. This should be safe.

JeodC avatar Apr 26 '24 23:04 JeodC

We gon do this one? The longer it stays, the more likely we'll run into merge conflicts.

tophyr avatar Apr 28 '24 06:04 tophyr

If they aren't used, there shouldn't be merge conflicts. I believe this is safe to merge though.

JeodC avatar Apr 28 '24 11:04 JeodC

If they aren't used, there shouldn't be merge conflicts.

lol, good point - my concern was more around the MACINTOSH ifdef's.

tophyr avatar Apr 28 '24 21:04 tophyr