-
Notifications
You must be signed in to change notification settings - Fork 0
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
Problems with building via CMake for Linux #1
Comments
Hey @NY00123, apologies I didn't notice this sooner! GitHub unfortunately does not seem to always notify you of issues logged against repositories that are not under an organization, unfortunately. I really appreciate your interest in this project, but unfortunately I have not officially released it yet and as such I haven't taken the time to provide much in the way of documentation or information since I have not publicly advertised this initiative either. I'm nearing a V1 release, but I've been on a little bit of a hiatus for a few months, busy with real life things. I plan to come back to this as soon as I have the opportunity. That said, indeed you are correct that this does not build on Linux, as I have not officially added support for this, but it is on my roadmap in the future. I've bridged out and used cross-platform libraries where it made sense to do so! I should have added a more explicit error in the CMake file when building for invalid target operating systems, so that is my mistake! That's strange that it's failing on 7-Zip... I use that SDK for two purposes:
For the latter, it requires the full SDK, but it is only built when the target platform is Windows. As for the old executable I provided on my website, this is the state of the project from nearly a decade ago and does not even remotely reflect it's current state. I have neglected updating my website for some time now, regrettably. Thanks for calling out the git module issue, didn't realize using SSH was problematic.. I will re-consider this. 👍🏻 And as for the project itself, a brief overview is that it is intended to allow you to play any number of the 500+ mods available for Duke Nukem 3D across a wide range of source ports and DOSBox versions (where required) with a high degree of customizability. I've put years of work into hand curating this mod collection and crafting a massive metadata file with all the relevant information. It's the most complete collection of mods that I'm aware of. I also painstakingly went through hundreds of mods and manually converted them to work with the Atomic Edition of Duke 3D instead of the original 1.3D version, including re-creating the CON files, writing tooling to merge ART file tiles together, automatically incrementing invalid sound identifiers used in MAP files, and much more. Really appreciate you taking the time to check this out, I'm happy to connect with you via e-mail or Discord or something if you wish to discuss further or learn more about the project in the interim! |
I see, no problem at all here. I assumed it was maybe just due to priorities around the time of my report, and/or not feeling it's ready for a release. From what I can tell, multiple people looking for Duke3D-related downloads would stumble upon your website over the years and get contents from there, but not use the older mod manager binaries or each mod's "Mod Manager Files"; And also not necessarily understand the purpose of the mod manager files from an inspected mod, if noticed.
Sounds like the usual and expected for me.
Thanks for confirming. Still wondering what may be done to resolve the "cmake" directory's case sensitivity issue; From what I recall, whenever I tried taking care of that, the whole structure would be recreated with the same problem. But if it's assumed there's no support, then that's just the situation for now.
So that's why the dependency exists. ZIP files seem to be used from your website, presumably read with some kind of built-in code.
Outside of the scope of customizability, that's been exactly my guess, more-or-less. I should note that there's potential competition coming from a new program of this kind; Namely, BuildLauncher from fgsfds. It might not currently have the same list of Duke3D mods as in your website, and it also lacks support for Vanilla Duke3D right now. But it's still there and further supports other Build Engine games.
That scope of work here is quite impressive, that's for sure. Are these modifications (to the mods themselves) usable without the manager, or the separate mod ZIP files have just unmodified data?
You're welcome! It's true I usually still don't use a mod manager, in case I do play a mod Duke3D. If it's a multiplayer game, a way to go is probably one of the multiplayer-centric launchers (with chat lobbies) that also let you use mods conveniently. Otherwise, I might still unpack mods manually. I may try playing old contents (like a map or a mod) as-is, even with bugs (while I'm aware of the possibility). If it was made for v1.3d, I'd use either DOS registered v1.3d or a source port with at least partial compatibility (multiplayer included). It should be known there are hardcoded Duke3D behaviors that differ between the executables of v1.3d and the Atomic Edition, while not being exposed via CON. |
Hi,
I don't know if support for platforms differing from Windows is covered right now. In fact, I have no idea if this software is intended to be used or maintained by other people; I couldn't really find discussions of it outside of your website, and
.gitmodules
currently uses an SSH remote URL instead of HTTPS. I suppose it's a program similar in idea to what you can get for games via the Steam Workshop, only that it covers mods for Vanilla Duke3D and/or unofficial source ports?Either way, I've been trying to build it. The old Windows executable from 2009 doesn't work for me (tested via Wine); I can tell it appears to depend on debug runtime DLLs from VC++ 2005.
After using a local installation of CMake 3.27.7, it seemed to start downloading various packages into ~/.hunter and preparing them, until it ended with the following error, probably for 7-Zip:
It looks like
BUILD_CPP_LIB
is set toON
for Windows and not set at all otherwise, judging from the value ofBUILD_7Z_CPP_LIB
as defined under the submodule fileLibraries/Core/CMake/Hunter/HunterConfig.cmake
.After re-running CMake with the addition of
-DBUILD_7Z_CPP_LIB=OFF
, it managed to progress until it reported the following file was not found:~/.hunter/_Base/5299724/f845a29/af3f2be/Build/SevenZip/Source/cmake/Config.cmake.in
It's apparently a problem of case sensitivity on Linux, because this file exists (emphasis on
cmake
vs.CMake
):~/.hunter/_Base/5299724/f845a29/af3f2be/Build/SevenZip/Source/CMake/Config.cmake.in
Unfortunately, renaming the directory or even making a copy didn't seem to assist - the whole structure would be re-generated from what I saw. Same with editing the location of
Config.cmake.in
within theCMakeLists.txt
file itself.Let's hope this report proves to be useful.
The text was updated successfully, but these errors were encountered: