search

encounter / dtk-template

Project template for decomp-toolkit
Creative Commons Zero v1.0 Universal
17 stars 14 forks source link

Support dolsdk2001 #19

Closed ribbanya closed 7 months ago

ribbanya commented 7 months ago

So I've been messing around with this branch for a couple days, trying to support dolsdk2001. I've gotten it to extract the archives, build the source files, and compare them using objdiff-cli. Profiles (release vs. debug) aren't fully supported yet.

Proof of concept

Branch changes

❯ ninja     
[2/89] TOOL build/tools/sjiswrap.exe
Downloading https://github.com/encounter/sjiswrap/releases/download/v1.1.1/sjiswrap-windows-x86.exe to build/tools/sj
iswrap.exe
[3/89] TOOL build/tools/wibo
Downloading https://github.com/decompals/wibo/releases/download/0.6.9/wibo to build/tools/wibo
[4/89] TOOL build/tools/objdiff-cli
Downloading https://github.com/ribbanya/objdiff/releases/download/v1.1.0/objdiff-cli-linux-x86_64 to build/tools/objdiff-cli
[32/89] TOOL build/tools/dtk
Downloading https://github.com/encounter/decomp-toolkit/releases/download/v0.7.4/dtk-linux-x86_64 to build/tools/dtk
[33/89] EXTRACT orig/DOLSDK-2001-05-22/os.a
Extracting orig/DOLSDK-2001-05-22/os.a to build/DOLSDK-2001-05-22/release/obj/os
Extracted 30 files
[89/89] CHECK build/DOLSDK-2001-05-22/report.json
OK

Inquiry

At this point, I'd like to stop hacking this together and instead go about it in a way that can be upstreamed.

  1. Do you want this use case to be supported? I imagine there are other libraries this methodology could be used for, but it's not a standard dol decompilation and I could understand wanting the dolphin SDK to just forge its own path.
  2. My branch completely deletes /config and circumvents the split/symbols features of dtk. Should dtk (rather than just the template) be modified to support libraries?
  3. If dtk supports libraries, should it also support the OK check, or should that still be handled by objdiff-cli?
  4. How do the dolphin build profiles (debug vs. release) interact with objdiff's plans to support -sym on?
  5. How should the lack of a link step be handled? Currently both project.py and dtk make a lot of assumptions about the existence of a linker.
encounter commented 7 months ago
  1. Yes, but not in dtk-template proper. I expect it to be a separate build system, since most of dtk-template's logic isn't necessary.
  2. What features would dtk provide in this case? I imagine ar extract, elf disasm... and that's about it. There's no split step. The build system is just calling mwcc and comparing with objdiff.
  3. No, loosely comparing objects is objdiff's purpose, imo. It may even make sense to move dtk dol diff over to objdiff proper.
  4. The SDK repo can just emit both release and debug together for now (e.g. gx, gxD, etc.) and switch to "profiles" later.
  5. Similar opinions to point 1 and 2.

To expand on point 1 and 2, we're dealing with two pretty different paradigms:

It would be possible to consider what they have in common and extract shared code, but I'm leaning towards the idea that it's better to keep them as two separate more focused project structures that happen to duplicate some code / ideas.

I'm happy to hear arguments otherwise, though, especially if there's ideas on how we could support both without complicating project.py even more.

ribbanya commented 7 months ago

That makes sense. So for now do you think the build system should live entirely on doldecomp/dolsdk2001 without trying to abstract it?

encounter commented 7 months ago

Yeah, for now. And I think dolsdk2001 should aggressively trim out everything that's unneeded.

ribbanya commented 7 months ago

Okay, cool. Closing this as it's no longer related to the dtk template.