• Dear Cerberus X User!

    As we prepare to transition the forum ownership from Mike to Phil (TripleHead GmbH), we need your explicit consent to transfer your user data in accordance with our amended Terms and Rules in order to be compliant with data protection laws.

    Important: If you accept the amended Terms and Rules, you agree to the transfer of your user data to the future forum owner!

    Please read the new Terms and Rules below, check the box to agree, and click "Accept" to continue enjoying your Cerberus X Forum experience. The deadline for consent is April 5, 2024.

    Do not accept the amended Terms and Rules if you do not wish your personal data to be transferred to the future forum owner!

    Accepting ensures:

    - Continued access to your account with a short break for the actual transfer.

    - Retention of your data under the same terms.

    Without consent:

    - You don't have further access to your forum user account.

    - Your account and personal data will be deleted after April 5, 2024.

    - Public posts remain, but usernames indicating real identity will be anonymized. If you disagree with a fictitious name you have the option to contact us so we can find a name that is acceptable to you.

    We hope to keep you in our community and see you on the forum soon!

    All the best

    Your Cerberus X Team

What I was working on before Xmas - A Cerberus-X Preview

Ok, then I will wait to test the buildscripts further till your new preview is ready. I had asked because depending on which variant I called the script, a tool didn't build. One time shared trans, then trans, or launcher. Ted was never build, but from within QT I can build it just fine. I will wait till your preview and report back.

Without the --git option it just copies from the files from the local repository.
Local repository == the top folder you run the package option in?

Powershell scripts is completely new to me and definitely something I need to learn.
 
Local repository == the top folder you run the package option in?
Yes the root directory of the locally cloned git repository that would be the main work copy of cerberus.
When I build Cerberus, I open a shell, change directory into cerberus/src and execute the rebuild all scripts from there.

The idea is that you have a full cloned git repository as your work copy. Here you can test out anything git related. Note you should make a backup of the local work repository before doing any merge or rebase in case things go wrong. Git is not entirely infallible:rolleyes:.

You can build all the tools within the local work copy of the git repository. Depending on the tools use to edit any source files, the line endings could be in either crlf or lf. The --package/-p just copies the files as they are from the local work git repository. The final result is a directory name cerbdeploy/build that is created in the users Documents directory where it can be check that the script is copying correctly. The last thing you would want is to copy over is either system specific files or a restricted licence library that you may have missed with .gitignore.

When the --git/-g option is passed it first makes a full clone of the local working repository into Documents/cerbclone fixing any line ending issues outlined in the .gitattribute file and the global git configuration settings. I have Git for Windows installed and use the fully cross platform GitKraken, it's free for non commercial use. If you are do commercial and none commercial, its best to use either the pro version, or go with a git client tool that doesn't place such restrictions, as long as that client installs git for use via the command line.

Special note here: git cannot process non UTF-8 encode files that you tend to find in the Windows world. Special care must be taken with xml files where the UTF in the file's xml header can be different to the actual file encoding (discovered that with the Window Phone target and resource files). It's best to set them as binary, eol=lf or at a push, the actual encoding may work. You should check again that the files are correct before actual deployment. Git was originally a Linux tool and ported over to the other operating systems.

The script then executes the freshly cloned rebuildall script with parameters that were passed, minus the --git option. It then takes over building within the new location. Once the build is done, it copies over the new built files (via the --packag/-p option) and compresses it ready for distribution. You can then check the local work repository and remove any temporary commits before pushing to the remote server.

EDIT:
The deploy package using git requires that it's a valid git repository. It will not work from a pre-built distributed package.

Edit2: One thing that needs a small change is the rebuildall.sh script setting files permissions too early.

Powershell scripts is completely new to me and definitely something I need to learn.
It's still new to me. I wouldn't mind getting my hands on Powershell Studio to make working with Powershell scripts easier. But it ain't frigging cheap. There is suppose to be a free community version, but I think that you have to create an account to get it.

My preferred tools are:
Those mentioned above (apart from Powershell Studio).
Visual Studio Code. It's cross platform, has a limited git client functionality that comes in handy when you don't want to mess around with your git client of choice. Has a built in terminal and limited script debugging depending on the platform is't being run on. It also supports the changing of line endings.
 
Last edited:
I just want to give you a thumbs up. I was not able to use JungleIde to compile for desktop with the official version, but with yours it works again. In between time I wrote with Jungle and compiled with ted ... not to much fun.
 
Well I was hoping to have some more previews up and running. But getting things to work in Windows that way that I want is causing a bit of a headache.

The idea is to have a new compiler detection module for transcc to use, and as always, it's Windows and it's tool chains that are causing a me a headache with having to check if MinGW is to be used or Visual Studio.

So for the time being, I'm will posting a link to the compiler detection code for people to compile and test. It's ugly, but better than doing a hack of transcc just to detect the all the versions of MinGW. Extract and place the dawlane directory into modules_ext.

I was not able to use JungleIde to compile for desktop with the official version, but with yours it works again.
It may break in the future.
 
Sounds like it is getting over engineered and to complicated.

If it is complicated for you, how will it be for the average Joe?
 
If it is complicated for you, how will it be for the average Joe?
It's trying to integrate the compiler module into transcc in clean way. I'm trying to think of ways to internally simplify stdcpp and glfw target code to make it more manageable to work with. The current version on the experimental branch is more of a hack of the original code, especially the stdcpp target and there's a bit of code duplication that would be better of in the parent class.

For the average Joe. They wouldn't need to have to set path's in config.winnt.txt for either MinGW or MSBuild, as the compiler module would try to get any installed compilers from known locations. But the editing of MinGW or MSBuild has to remain an option to set the compiler.
Once I've figured it out, it shouldn't as complicated as having to write code for the translator. It's just wrapping my head round the best way to make sure that the right compiler tool chain is being used at the right time.
 
So what happens when you have both compilers installed?
If both are installed, and no paths are set. Then the detection module will scan known locations for both MinGW and Visual Studio. If both are installed; then both will be stored into a stack. The default will always to try to use MinGW. If MinGW isn't found; then it will try to use Visual Studio.

I think I've got it sorted and working the way that I want, so either later today or tomorrow I will have a Windows test version uploaded.
It's not easy trying to debug transcc with transcc when messing around with the basic core build system. It can drive you :mad:.

The only decision I have to make is whether to leave the common routines for glfw and stdcpp as functions in the helper files, or place them into the builder files as methods. Using the routines as functions means that the class reference has to be passed as a function parameter, but leaves the builder class as is with only a few extra variable fields.

Here's basically how it should all work:

The Detection module:
Other than having a hundreds of check sums for binaries. The easiest solution is to try and execute the compiler and get any version information from the resulting output that can be scanned for meaningful information.

By passing search paths, you can check for valid executable files for MSBUILD, GCC, XCODEBUILD and CLANG (Mac OS).
If there are multiple paths passed and each one is to a valid compiler executable, then each one will be stored. Duplicates are not stored. So if two path were given and the executable is the same version; then only the first one found is stored.

MinGW: user paths, default locations C\: and a Environment variable named MINGW are checked.

Visual Studio 2015/2017: user paths, C:\Program Files\MSBuild, C:\Program Files\Microsoft Visual Studio\...etc
Note: For Visual Studio 2017 update 2 Microsoft introduced a tool to locate Visual Studio installations. This is checked first for Visual Studio 2017 update 2+ and ignores any paths passed.​

Linux and Mac OS don't need serious detection with them basically being already in the environment search path.

transcc:
The MINGW_PATH and MSBUILD_PATH are used to over-ride auto detection and should return any compilers at the beginning of the compiler list. There is no need to add msbuild.exe to MSBUILD_PATH as the executable would be part of the compiler data.

Two new config.winn.txt variables are used for Visual Studio. VS_DEFAULT and VS_VERSIONS. The latter is a semi colon separated string with Visual Studio year versions, while the former is what the current version Cerberus is to use as a default.

Three new common functions have been for glfw and stdcpp.
  1. SelectVSTUDIO: Use to select which Visual Studio version to use based on GLFW_VSTUDIO_VERSION and CC_VSTUDIO_VERSION.
  2. SetWindowsDesktopCompiler: Used to select either MinGW or Visual Studio based in the detected compilers and status GLFW_USE_MINGW and CC_USE_MING. If only one compiler is found, the preprocessor directives are ignored.
  3. CheckMSize: Used to select the binary architecture to output based on the values in the MSIZE preprocessor directive type.
sharedtrans also uses the compiler detection module, as it was need to implement caching of library files. So the first run searches and caches, while the next run loads the cache file, checks that the right library is to be copied. This is doubly so for MinGW run-times.
 
New one for testing.

I'm only putting the Windows version up for now as there is an odd bug where some errors are not being trapped in debug mode and I'm not sure what's going on. Try writing some test programs that throw index out of range and access violations. It seems to affect compiling with MINGW, but I have seen this issues with Visual Studio in C++Tool builds. I remember that there was an issue in MonkeyX where certain exceptions were not being caught in C++Tool targets. I get different results with Jungle and Ted, so I'm suspecting that The problem may be to do with piping stdout/stderr with one of the functions I've added, but I don't fathom how that would affect it.

As far as I can tell the Linux builds are not affected.

Cerberus X 2018-11-02 msbuild

Note: I've not push any thing to get yet, until it can be figured out.
 
Last edited:
CX examples and desktop/console targets work fine.
My AGK target doesn't work as it can't find the MS tools, even if I set the path in the config file, like I do in the official version.

EDIT: The copy_shared_test doesn't compile anymore. Can't find MSVC.
 
Last edited:
My AGK target doesn't work as it can't find the MS tools, even if I set the path in the config file, like I do in the official version.
I didn't update that part, but replace the part calling MSBuild with
Code:
Execute "~q"+tcc.compiler.Path+"/"+tcc.compiler.Executable+"~q /p:Configuration="+casedConfig+" "+buildpath+"\Template.sln"
should fix that bit.

Using the old method of setting the full path to msbuild will not work. The compiler detection should construct the full path.
I'm also thinking that may be json file should be used for parts instead of trying to rip information from the command line.

The sharedtrans application will always report that it cannot find Visual Studio when compiling with MinGw. And that's because it's not reading the config text files to get the additional bit of data that transcc uses. I may have to add some addition parameter passing.

The odd bug where exceptions are not being caught is going to be a bit of a pain to try to locate and fix.
 
Ok, tried the powershell rebuildall.ps1 command with MSVC2017

.\rebuildall.ps1 -msbuild -vsversion "2017"

or

.\rebuildall.ps1 -msbuild

gives an error when building trans.

Code:
========= CERBERUS BUILD SCRIPT =========
========= NO WARRANTIES. USE AT OWN RISK =========
========= STARTED: 11/28/2018 20:05:31 =========

========= Current parameters =========
This script is at C:\users\mike\desktop\cerberus-msbuild\src.
The Cerberus root directory is at C:\users\mike\desktop\cerberus-msbuild.
MinGw is set to C:\Mingw.
Qt SDK is set to \5.9.2\msvc2017.
Visual Studio is at C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC.
w64 Static build switch is set to False.
MSBuild switch is set to True.
32/64 build swith is set to False.
This script is running on a 64 bit operating system. Therefore 64 bit binaries will be built.
QtSDK tools changed from \5.9.2\msvc2017 to \5.9.2\msvc2017_64

========= Testing build environment =========
Added C:\Mingw, C:\Qt\5.9.2\msvc2017_64 and C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin; to current shell environment path.
Testing for qmake
EXECUTING: qmake -v
OK: Executed
QMake version 3.1 Using Qt version 5.9.2 in C:/Qt/5.9.2/msvc2017_64/lib

Testing for Visual Studio VC
VC Tool chain enviroment already initialised.

========= Checking for config.winnt,txt =========
OK: Found config.winnt.txt

========= Extracting archives if any =========
Extracting C:\users\mike\desktop\cerberus-msbuild\src\archives\libs\winnt\shared_libs_win.zip to C:\users\mike\desktop\cerberus-msbuild\libs\shared
Extracting C:\users\mike\desktop\cerberus-msbuild\src\archives\libs\winnt\static_libs_mingw.zip to C:\users\mike\desktop\cerberus-msbuild\libs\static
Extracting C:\users\mike\desktop\cerberus-msbuild\src\archives\libs\winnt\static_libs_visualstudio.zip to C:\users\mike\desktop\cerberus-msbuild\libs\static
Extracting C:\users\mike\desktop\cerberus-msbuild\src\archives\licences.zip to C:\users\mike\desktop\cerberus-msbuild\libs\
Extracting C:\users\mike\desktop\cerberus-msbuild\src\archives\icons.zip to C:\users\mike\desktop\cerberus-msbuild\src\archives\

========= Building transcc from Cerberus Source =========
Please wait
A backup of transcc_winnt has been detected. Do you wish to restore to rebuild transcc? (Y)es/(N)o
Answering No will replace the backup with the current version of transcc_winnt.
Answer Y/N: y
Deleting current.......
OK: Deleted C:\users\mike\desktop\cerberus-msbuild\bin\\transcc_winnt.exe
Restoring back up copy....
OK: Copied C:\users\mike\desktop\cerberus-msbuild\bin\transcc_winnt.exe.bak to C:\users\mike\desktop\cerberus-msbuild\bin\transcc_winnt.exe
EXECUTING: C:\users\mike\desktop\cerberus-msbuild\bin\transcc_winnt.exe -msize=64  -msbuild -vsversion="2017" -target="C++_Tool" -builddir="transcc.build_new" -clean -config="Release" "transcc\transcc.cxs"
TRANS cerberus compiler V2018-11-02 preview
Compiler detection
WARNING: MinGW not found.
Detected: 0 MinGW compilers.
Check that you have MinGW installed And set up correctly If you are using it.


Parsing...
Semanting...
Translating...
Building...


Deleted old icon resource file C:/users/mike/desktop/cerberus-msbuild/src/transcc/transcc.build_new/cpptool/msvc2017/Release64/main.res
Copying icon from Cerberus resource directory to C:\users\mike\desktop\cerberus-msbuild\src\transcc\transcc.build_new\cpptool/icon.ico


USING COMPILER TOOL CHAIN: Visual Studio 2017
Over-ride of CC_USE_MINGW via the command line option -msbuild.
Over-ride of Visual Studio default 2017 via command line option -vsversion.

Location: C:\Program Files (x86)/Microsoft Visual Studio/2017/Community/MSBuild/15.0/Bin/
Over-ride of CC_VS_MSIZE_WINNT via command line option. MSIZE is now set to 64bit.  An error will be generated by the compiler if it's not supported.
Executing C:\Program Files (x86)/Microsoft Visual Studio/2017/Community/MSBuild/15.0/Bin//msbuild.exe /p:Configuration=Release64 /p:projectname="main_winnt" /p:CerberusPath="C:/users/mike/desktop/cerberus-msbuild" /p:CerberusLibraryPaths="" /p:CerberusIncludePaths="" /p:CerberusLinker="" /p:CerberusIncludes="" /p:CerberusDefines="" /p:CerberusCompilerOpts="" /p:CerberusResDefs="__USE_ICON__"
Microsoft (R)-Buildmodul, Version 15.7.179.6572 für .NET Framework
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

Die Projekte in dieser Projektmappe werden nacheinander erstellt. Um eine parallele Erstellung zu ermöglichen, müssen Sie den Schalter "/m" hinzufügen.
Der Buildvorgang wurde am 28.11.2018 20:05:46 gestartet.
Projekt "C:\users\mike\desktop\cerberus-msbuild\src\transcc\transcc.build_new\cpptool\msvc2017\main.sln" auf Knoten "1"
(Standardziele).
ValidateSolutionConfiguration:
  Die Projektmappenkonfiguration "Release64|x64" wird erstellt.
Das Projekt "C:\users\mike\desktop\cerberus-msbuild\src\transcc\transcc.build_new\cpptool\msvc2017\main.sln" (1) erstel
lt "C:\users\mike\desktop\cerberus-msbuild\src\transcc\transcc.build_new\cpptool\msvc2017\main.vcxproj" (2) auf Knoten
"1" (Standardziele).
PrepareForBuild:
  Das Verzeichnis "Release64\" wird erstellt.
  Das Verzeichnis "Release64\main_winnt.tlog\" wird erstellt.
InitializeBuildStatus:
  "Release64\main_winnt.tlog\unsuccessfulbuild" wird erstellt, da "AlwaysCreate" angegeben wurde.
ClCompile:
  C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX86\x64\CL.exe /c /Zi
   /nologo /W0 /WX- /diagnostics:classic /O2 /Oi /D _CRT_SECURE_NO_WARNINGS /D __VISUAL_STUDIO__ /D _WIN32 /D WIN32 /D
  NDEBUG /D _CONSOLE /D _LIB /D _UNICODE /D UNICODE /Gm- /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inl
  ine /Fo"Release64\\" /Fd"Release64\vc141.pdb" /Gd /TP /FC /errorReport:queue /bigobj ..\main.cpp ..\stdafx.cpp
  main.cpp
  stdafx.cpp
  Code wird generiert...
ResourceCompile:
  rc.exe /D __USE_ICON__ /D _UNICODE /D UNICODE /D _UNICODE /D UNICODE /l"0x0409" /nologo /fo"Release64\main.res" ..\ma
  in.rc
  TRACKER : Fehler TRK0005: Fehler beim Suchen von "rc.exe". Das System kann die angegebene Datei nicht finden.


C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(1454
,5): error MSB6006: "rc.exe" wurde mit dem Code 5 beendet. [C:\users\mike\desktop\cerberus-msbuild\src\transcc\transcc.
build_new\cpptool\msvc2017\main.vcxproj]
Die Erstellung des Projekts "C:\users\mike\desktop\cerberus-msbuild\src\transcc\transcc.build_new\cpptool\msvc2017\main
.vcxproj" ist abgeschlossen (Standardziele) -- FEHLER.

Die Erstellung des Projekts "C:\users\mike\desktop\cerberus-msbuild\src\transcc\transcc.build_new\cpptool\msvc2017\main
.sln" ist abgeschlossen (Standardziele) -- FEHLER.


Fehler beim Buildvorgang.
 
OK. Been a bit since I did any work on this project as a result of being a bit down after having some test and the doctor told me I have to now go on a strict gluten-free diet, which is a real pain. The only real tragedy is that I can no longer drink lager with it having gluten in it:(

The odd bug where exceptions are not being caught is going to be a bit of a pain to try to locate and fix.
Looks like this bug could be down to exception handling as the only MinGW compilers not affected are either dwarf or seh.

But MinGW compilers using sjlj are having issues:
  • i686-w64-sjlj compiles 32 bit mode OK and exceptions caught, but fails to link when compiling 64 bit applications.
  • x86_64-w64-sjlj compiles 32 bit mode OK and exceptions caught, but compiles 64 bit OK and exceptions not caught.
 
No. Not until I've figured out the situation with MinGW sjlj compilers.
I've done some research into it, and there is no easy fit solution other than either:
  • Drop either 32 or 64 support for MinGW.
  • Make it possible for both the the 32 dwarf and 64 bit seh to live side-by-side.
Even the the MinGW-w64 team don't recommend the use of sjlj. Though the patent held by what was Borland for 32bit stacked based seh should have expired by now, I cannot see that ever being implemented with everything moving to 64 bit.

About Ted:
Ted will not work correctly after Qt5.9.7.
  • Issue with webengine
  • Issue with Project browser
I've improved the image viewer, added a audio file preview dialog and updated the IDE options to use a tabbed toolbox.
One known issue is that Ted crashes on exit on Windows with back trace pointing to webengine. Not sure if this has something to do with the recent Windows updates, or an issue with my Visual Studio Installation. Information on this is scarce and the only information points to a user code error.

I will upload some builds and sources later.
 
Well all i can say is 2 things.

Cx will stay 64bit. And Ted doesn't crash here.
 
Back
Top Bottom