You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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 pathsreccmp-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 pathsThere are several reasons for this design decision:
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
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 generatereccmp-build.yml
files without a python/reccmp dependency and also without worrying to accidentally destroy information.The text was updated successfully, but these errors were encountered: