Xeeynamo
Clean up and unify build pipeline and folder structure
The current build pipeline involves multiple distinct logical workflows; us, pspeu, and saturn. The hd version follows the us version process, but has a couple things specific to hd.
The makefiles and build structure need to be unified and brought into a common framework so that they are consistent and intuitive, but also so that it is only necessary to understand a single logical workflow to make changes, instead of a unique structure for each version. Part of this should also include changes to minimize and simplify changes that need to be made directly within the makefiles themselves.
There don't seem to be any functional issues with the us and psp workflows, but the saturn workflow has a few bugs.
Two breaking bugs in the saturn workflow that are addressed within #2188 :
- The st% pattern intended for us/hd versions also incorrectly applies to saturn version stage_02.prg
- This is fixed as a result of moving the st% pattern into the psx specific file, only getting included for us and hd versions
- The dosemu dependencies were not properly included in the dependencies list
The remaining bug that I have discovered will be mitigated in #2196 :
- dosemu cannot support multiple jobs as the current workflow is written, causing the build to fail when -j/--jobs is used
- I am still looking for a way to support -j, but as an interim mitigation I will disable -j for the target in question
Some questions/comments from @hohle that I thought would be relevant to include both the questions and answers here.
From an organizational perspective, I find it odd that the default targets are not in Makefile. If I were just coming into the project, that's where I'd first look for the default targets.
Does anybody else have an opinion on this? I personally think make help and the wiki are sufficient, but I'm happy to adjust my way forward to align with the group as a whole.
I'm not sure I like this better than listing the objects in the Makefile. Makefiles frequently have lists of dependencies and these are effectively static. What advantage is there to moving these to separate files?
This is in regards to including the list of merged functions in a separate file versus directly in the makefile itself. I think the best option would be to leverage the splat config if possible, does anybody else have opinions on this?
Does this fix any relationships between symbols, splat config, and built overlays? one of the pain points for me is missing dependencies between the recipes which forces frequent cleans between rebases, segment splits, etc.
This is also a pain point for me, I am aiming to have make only build those targets which have been touched and need rebuilt.
Does this impact build times at all with parallel builds? I didn't see anything that looked like it would, but wanted to double check.
Not increasing the build times is a personal requirement for me, but ideally I'd like to decrease them.
The headline of the issue is great. I share the same concerns and observations you wrote.
From an organizational perspective, I find it odd that the default targets are not in Makefile. If I were just coming into the project, that's where I'd first look for the default targets.
Does anybody else have an opinion on this?
I agree with @hohle . Default targets should be in the Makefile.
I'm not sure I like this better than listing the objects in the Makefile. Makefiles frequently have lists of dependencies and these are effectively static. What advantage is there to moving these to separate files?
This is in regards to including the list of merged functions in a separate file versus directly in the makefile itself. I think the best option would be to leverage the splat config if possible, does anybody else have opinions on this?
I share the sentiment. Let's keep it simple. In an ideal world, everything should be interconnected and data-driven. But I also think about maintainability, where often stupidly simple approaches are preferred over attempting to reduce duplication with complex solutions.
I share the sentiment. Let's keep it simple. In an ideal world, everything should be interconnected and data-driven. But I also think about maintainability, where often stupidly simple approaches are preferred over attempting to reduce duplication with complex solutions.
This resonates with me greatly and I agree wholeheartedly. After being "forced" to adjust my approach, I see that I was starting to overcomplicate things.
Please note that I say forced without a touch of negativity.