Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project file hierarchy #7

Open
madebr opened this issue Oct 24, 2024 · 1 comment
Open

Project file hierarchy #7

madebr opened this issue Oct 24, 2024 · 1 comment
Labels
cleanup Fix the leftovers of a major migration

Comments

@madebr
Copy link
Contributor

madebr commented Oct 24, 2024

I created this issue to discuss project file hierarchies.

#1 requires 3 project files, of which only one should be committed to a project's source repo:

  • reccmp-project.yml is supposed to be pushed to a git repo, and should not contain absolute paths
  • reccmp-user.yml should not be part of a git repo, and is supposed to be modified by the user (although the tools can initialize it with defaults). This file can contain absolute paths.
  • reccmp-build.yml should also not be commited to the repo, and is supposed to be modified by the build systems, and can contain absolute paths

There are several reasons for this design decision:

  • split public (=reccmp-project.yml) information and private (=reccmp-user.yml & reccmp-build.yml) information.
    It should be up to a developer to choose where and how binaries are stored and/or built
  • split information that usually remain stable in a project (reccmp-user.yml), and information that depends on a build (reccmp-build.yml). Another reason for splitting -user.yml and -build.yml is that it allows a CMake project to generate reccmp-build.yml files without a python/reccmp dependency and also without worrying to accidentally destroy information.
@jonschz jonschz added the cleanup Fix the leftovers of a major migration label Oct 27, 2024
@jonschz
Copy link
Collaborator

jonschz commented Nov 16, 2024

Finally getting around to responding here.

First of all, the split into a reccmp-project.yml that is checked into git, and a reccmp-user.yml that is not checked into git sounds very reasonable to me, no need to discuss that point from my side.

Regarding the reccmp-build.yml I am a bit torn. Here are some thoughts:

  • I don't see a lot of good arguments to remove it now that we already have it. Biggest counterargument is that it can make setting up the local repo for a new user a tiny bit harder, but that's not a big issue in my opinion.
  • For Lego Island I consider this extra file to be slightly overkill (its information could go into the user file, imho). There might be other projects where it makes more sense to have a separate file, though. I haven't been involved with other decompilation projects so I can't comment on that.
  • Personally, I don't get any benefit from having two files since I need to set up a non-changing, custom reccmp-build.yml for my personal Lego Island setup. There reasons for that are as follows:
    • The Ghidra import script cannot know where the recompiled files are, so the reccmp-build.yml must be located next to the reccmp-project.yml, which invalidates the benefit of being able to generate the file during the build process within the build directory.
    • This point is Lego Island specific: I often decompile the same LEGO1 and BETA10 function simultaneously. My recompiled LEGO1 is located under /build while my recompiled BETA10 is located under /build_debug. I have one console open where I alternate between reccmp-reccmp.exe --target LEGO1 --verbose <lego1address> and reccmp-reccmp.exe --target BETA10 --verbose <beta10address>, and I don't want to cd all the time. This cannot be done without a custom setup for the reccmp-build.yml that does not get overwritten.

Looking forward to your thoughts!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup Fix the leftovers of a major migration
Projects
None yet
Development

No branches or pull requests

2 participants