Refactor of 4ed_build

[saccarosium]

I've made the following changes to 4ed_build.cpp:

• Always create a working 4coder installation
• Put everything in the build directory
• Separate builds with <architecture> subfolder in build
• Put zip files in the same place as the folder

Before PR

After doing cd code && .\bin\package.bat

build\
current_dist_super_x64\
| 4coder\
| | 4ed.exe
distributions\
| 4coder\
| | zipfile
code\
non-source\
.gitignore
README.md

After PR

After doing cd code && .\bin\package.bat

build\
| x64\
| | 4coder\
| | | 4ed.exe
| | zipfile
code\
non-source\
.gitignore
README.md

Next Step

This is only a first step to unify and simply the build process for 4coder

[Jack-Punter]

Nice one! Thanks for doing this. Looks like mac and linux packaging is failing in CI (I need to figure out why I had to approve the pipeline to start 🤔) I assume because the output structure has changed a little.

I think its probably worth also cleaning up the script files. I don't really see much point in our package scripts anymore, can you remove them and update the build instructions in the readme too?

Also now is probably a good time to update the arch_names I think we should probably remove x32 and add arm (for mac's see #17)

[saccarosium]

I've made the changes you've mentioned and also added to the 4ed_build.cpp architecture detection so we can just have the build scripts and the compiler can do the rest.

Is it an issue for Release action?

[Jack-Punter]

Couple points on some bits relating to the build context.
You're also going to need to update the github actions as this changes how you do a build and the pipeline steps are defined by the current branch not the destination branch. The changes should look something like this patch:

diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
index 9bc661a..1dc2858 100644
--- a/.github/workflows/build.yml
+++ b/.github/workflows/build.yml
@@ -11,19 +11,19 @@ jobs:
         include:
         - suffix: x64-win-dx11
           os: windows-latest
-          build_cmd: bin\package.bat /DWIN32_DX11
+          build_cmd: bin\build.bat /DWIN32_DX11
         - suffix: x64-win-gl
           os: windows-latest
-          build_cmd: bin\package.bat /DWIN32_OPENGL
+          build_cmd: bin\build.bat /DWIN32_OPENGL
         - suffix: x64-linux
           os: ubuntu-latest
-          build_cmd: sudo apt update -y && sudo apt install build-essential libx11-dev libxfixes-dev libglx-dev mesa-common-dev libasound2-dev libfreetype-dev libfontconfig-dev -y && ./bin/package-linux.sh
+          build_cmd: sudo apt update -y && sudo apt install build-essential libx11-dev libxfixes-dev libglx-dev mesa-common-dev libasound2-dev libfreetype-dev libfontconfig-dev -y && ./bin/build-linux.sh
         - suffix: x64-mac
           os: macos-15-intel
-          build_cmd: ./bin/package-mac.sh
+          build_cmd: ./bin/build-mac.sh
 #       - suffix: arm64-mac
 #         os: macos-latest
-#         build_cmd: ./bin/package_arm64-mac.sh
+#         build_cmd: ./bin/build_arm64-mac.sh
     runs-on: ${{ matrix.os }}
     steps:
     - uses: actions/checkout@v4
@@ -34,5 +34,5 @@ jobs:
       uses: actions/upload-artifact@v4.6.0
       with:
         name: 4cc-${{ matrix.suffix }}
-        path: current_dist_super_x64/4coder/  # having "x64" in path might have to change
+        path: build/  # or whatever the output directory is

[Jack-Punter]

Nice looks good, just a quick one on the pipeline (we still need to fix arm builds so just leave those commented for now). Once thats done ill do some tests on my various machines (dont have mac but have a few different linux boxes) then i'll look at merging

[saccarosium]

dont have mac

I've some macs I can test it myself

Also I actually know a lot about POSIX shell scripting so if you want I can merge the two build script into one both for linux and mac (and possibly other unixes)

[Jack-Punter]

Builds nicely on my ubuntu24.04 and 20.04 boxes.
There's a couple mentions of the package still in the readme which need removing.
I'll test on my windows machine when i get home from work .
I did notice that launching with -U 4coder_fleury causes a segmentation fault, but it also doesn't work on maseter, so ill raise that as an issue and see what it takes to make that work.

[saccarosium]

On 7 January 2026 13:52:05 CET, "Jack Punter - notifications at github.com" ***@***.***> wrote: Jack-Punter left a comment (4coder-community/4cc#49) There's a couple mentions of the package still in the readme which need removing.

Ok I will check them when I am at home

[saccarosium]

Ok I've updated the README with the new instructions

[Jack-Punter]

Looks good. I've tested on ubuntu20 and 24 as well as my windows 10 machine and seams to working nicely. I'll leave to see if we get any input from the other @4coder-community/maintainers in case they have any extra comments

[mrmixer]

I'd like to ask for the optimized builds to generate pdbs on Windows ( -Zi flag).

The "Build script parameter" section of the readme also needs to be updated I think.

[saccarosium]

I'd like to ask for the optimized builds to generate pdbs on Windows ( -Zi flag).

Do you mean in 4coder itself in the 4ed_build.cpp

[mrmixer]

PDBs for 4ed.exe and 4ed_app.dll .

I also wonder if we should "forward" the custom layer with the "release" argument to build_super.bat when we compile 4coder with optimizations. It doesn't matter for people that compile their custom layer, but that way the default layer would have optimization in releases.

[saccarosium]

PDBs for 4ed.exe and 4ed_app.dll.

Ok, I should be able to do it by adding the DEBUG_SYMBOLS to the flags in OPT_MODE

I also wonder if we should "forward" the custom layer with the "release" argument to build_super.bat when we compile 4coder with optimizations. It doesn't matter for people that compile their custom layer, but that way the default layer would have optimization in releases.

I was thinking to touch the custom layer script and refine the build process in another PR. Simply to make the PR not too big. But I can do it now

[mrmixer]

If you're talking about DEBUG_INFO I don't think it's the good way at the moment.

• On windows it will cause -DDO_CRAZY_EXPENSIVE_ASSERTS to be define which we don't want (it's not used anywhere in the code base, but it's a define to enable slow debug stuff when it's needed).
• On linux and Mac it would cause -O0 to be used.

I think we always want to generate debug info on windows because it's an external file (the pdb). On linux and Mac I believe debug info are in the executable directly (is that right ?) so I don't know that we want them at all time ?

@Jack-Punter What do you think ?

[saccarosium]

On linux and Mac I believe debug info are in the executable directly (is that right ?)

Yes, it is correct.

If you're talking about DEBUG_INFO I don't think it's the good way at the moment.

Ok, how should I do it then?

[mrmixer]

I was thinking to touch the custom layer script and refine the build process in another PR. Simply to make the PR not too big. But I can do it now

I think modifying the custom layer script should be another pr. But since the core build call the custom layer script, maybe we may want to forward the optimization request (the custom layer script already supports the release argument).

[mrmixer]

Ok, how should I do it then?

On windows I would always have the -Zi flag set. For linux and Mac I don't know. I'd like the feedback of the others if possible.

[saccarosium]

Ok, I've made so the build script passes the optimizations to the custom layer scripts. This works only on windows since is the only one that implements correctly the release flag.

I think that we should just merge this and then do a separate PR for tackling the other issues. The custom\build(.*).bat and custom\build(.*).sh aren't semantically equal.