Closed illwieckz closed 7 years ago
Do you want me to also test generation?
@Viech why not, I now added a make clean
target.
except English phrasing, it looks like I addressed all the issues reported.
for information, there is no one shell script anymore, everything is now python3 driven.
I get a different <key name="template_version" value="6351" />
than the versioned one in build/gtkradiant/install/pkg/scripts/default_project.proj
but otherwise I can reproduce your build.
Is there maybe a more elegant way of providing the generated files without having them versioned in this repository? Some sort of CI tool with packaged output that we can just link to?
Also, do you think it's worthwhile to move the generation scripts to @DaemonEngine and work with submodules? I wouldn't do that in this very PR, just a general question.
I get a different
than the versioned one
From gtkradiant:install/installs/Q3Pack/install/baseq3/scripts/default_project.proj
:
<!-- bump template_version to force a regen of the user project file from the template. Useful when tweaking the commands -->
<key name="template_version" value="8"/>
From mkeditorpacks/tools/buildmenu.py
:
d = datetime.utcnow()
tv = d.day + d.month * 32 + (d.year - 2000) * 367
add('template_version', tv) # increase every update
Yes, it's ugly, that's why I really don't like GtkRadiant.
Is there maybe a more elegant way of providing the generated files without having them versioned in this repository? Some sort of CI tool with packaged output that we can just link to?
Well, we can make the build/ directory as a submodule and git push it after generation… But it will ends with as many as submodules as fingers in one hand for just a couple files… :cry:
Also, do you think it's worthwhile to move the generation scripts to @DaemonEngine and work with submodules?
That was my first want, by the way, I merged them back because there is no urge to do it, and I prefer to see the changes merged without having to wait on the answer "do I have to publish that tool on @DaemonEngine and under which name", and well, I just want to get rid of it if possible.
Yeah as I said, there is no urge in splitting and moving the repository. All in all it looks really good to me, I would just fix the license before a merge.
I added license file and headers in mkeditorpacks
.
I also removed the omap.py
file since it was not used.
License nitpicks shouldn't prevent a merge. Go ahaed!
nitpicks fixed too :stuck_out_tongue:
so let's go!
Many improvements, original work discussed in #1, commits from mkeditorpacks were merged back in this tree (can be split later as submodule if needed).
notable change: build files are now in a
build/
parent dir. This means both netradiant and gtkradiant build script must use this new path to get their gamepack. By the way, no one supports unvanquished and no one fetches the unvanquished gamepack yet, so it's just changing something that is not yet used.[Edit: see illwieckz/unvanquished-mapeditor-support/tree/improvements for a preview]