@Fred / freak:
Would it be possible for you to change the build- and library-system? Beside what has been said already,
I still think you make your life harder than it needs to be.
Code: Select all
Function() (Ascii)
Function_THREAD() (Ascii + Threaded)
Function_UNICODE (Unicode)
Function_UNICODE_THREAD (Unicode + Threaded)
Function_Debug() (Runtime Debug)
When creating PB-Libs, we usually create 5 files for this 5 functions. It is an optimization thing, so every function
goes into an extra .obj within a .lib, and unnecessary functions are not linked into the final executable.
(I'm not sure all newest linkers address this issue using the flag for link-time-optimizations)
When modifying the build-system, you could only have 1 file, 'function.c'. Then, recompile it
using different flags (ascii/unicode, threaded ascii/threaded unicode).
I don't know about what build-times we are talking here. It could be 16 hours for a complete build,
and without ASCII support it could be 10 or 12 hours only. If it is in that range, it is an significant improvement.
I could be totally wrong and it could be 32 hours vs. 20 hours for a complete build for 3 platforms and ascii/unicode/threaded/32bit/64bit/MMX/SSE/SSE2/SSE3/SSE4/etc...
I see the bigger problem in maintenance, when you have 5 different functions in 5 files, instead 1 function and 1 file.
Using some smart C macros, in combination with compiler flags and some more #define, I think it should be
possible to re-compile 1 source file to many different targets.
I mean, in C/C++ I can also re-compile the same file for ASCII and UNICODE and SSE and SSE4 by using just different compiler flags
and putting all text strings into macros like _T("Hello") or TEXT("World"). ( "Hello" vs. L"Hello", you know )
Function names like MyFunction / MyFunction_Unicode / MyFunction_MMX / MyFunction_Threaded_Unicode_SSE4
can easily be generated automatically using macros and compiler flags/defines.
Of course this wouldn't affect the build-times in a positive way, if you still compile one file 5 times, just with different compiler flags.
But it would affect the maintenance time significantly, because you only manage 1 file with 1 function and just re-compile it for:
Code: Select all
- Ascii
- Ascii MMX
- Ascii SSE
- Ascii SSE2
- Ascii SSE3
- Ascii SSE4
- Threaded Ascii
- Threaded Ascii MMX
- Threaded Ascii SSE
- Threaded Ascii SSE2
- Threaded Ascii SSE3
- Threaded Ascii SSE4
- Unicode
- Unicode MMX
- Unicode SSE
- Unicode SSE2
- Unicode SSE3
- Unicode SSE4
- Threaded Unicode
- Threaded Unicode MMX
- Threaded Unicode SSE
- Threaded Unicode SSE2
- Threaded Unicode SSE3
- Threaded Unicode SSE4
- Debug
I think the PureBasic library system, and how you write PB library functions, could also be improved to make your life, and the maintenance part of PB, easier.
The big question is, what disturbs you more? Is it the build-times, or the maintenance of the many different function versions and files?
If the bottleneck is the build-times, you can't do much (assuming only changed files are re-compiled and tools like
ccache are used,
in addition to compiling 16 sources simultaneously on a build-machine with 8 cores and HyperThreading, enough RAM, SSD disks, etc.)
If the main problem is maintenance, I think you could improve some things within the PB library system, without dropping support for ASCII mode.
Living without ASCII mode is not a big problem in my opinion (after getting used to it), but of course it would be generally better to continue to support both modes,
if easily possible and maintainable.