WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V3.1.0 June 4, 2023)

[deltarho[1859]]

@thrive4

If you look at the first line of Editor in the 2.1.9 release, it mentions "You can still use different backend toolchains via the SetCompilerPaths plugin."

So, you can add fbc 1.08.0/gcc 9.3.0 (SJLJ exceptions) and fbc 1.08.0/gcc 5.2.0 and safely remove the current 1.07.2/5.2.

If you encounter any problems, you can come back to me - I wrote SetCompilerPaths.

This is what my setup looks like presently:


with SetCompilerPathsII.ini as:

Code: Select all

"5.2 MinGW-W64 1.08.0", "..\FreeBASIC-1.08.0-mingw64-gcc-5.2.0\fbc32.exe", "..\FreeBASIC-1.08.0-mingw64-gcc-5.2.0\fbc64.exe"
"8.3 ES 1.08.0", "..\FreeBASIC-1.08.0-gcc-8.3EQ\fbc32.exe", "..\FreeBASIC-1.08.0-gcc-8.3EQ\fbc64.exe"
"9.3 WL 1.08.1", "..\FreeBASIC-1.08.1-gcc-9.3\fbc32.exe", "..\FreeBASIC-1.08.1-gcc-9.3\fbc64.exe"
"9.3 Official", "..\FreeBASIC-1.08.0-winlibs-gcc-9.3.0\fbc32.exe", "..\FreeBASIC-1.08.0-winlibs-gcc-9.3.0\fbc64.exe"
"10.3 MSYS2 1.08.1", "..\FreeBASIC-1.08.1-gcc-10.3\fbc32.exe", "..\FreeBASIC-1.08.1-gcc-10.3\fbc64.exe"
"12.0 ES 1.08.0", "..\FreeBASIC-1.08.0-gcc-12\fbc32.exe", "..\FreeBASIC-1.08.0-gcc-12\fbc64.exe"

The first and fourth are from your news thread link - the other four are not public domain.

[PaulSquires]

Hi all, I intend to update the bundled FBC toolchain once CodeJeff and the developers touch up some of the small issues from the latest compiler release and release an update.

[thrive4]

@PaulSquires

Great news thank you in advance will wait patiently.

@deltarho[1859]

Also gracias for the feedback just out of curiosity I gave
your suggestions a whirl just some feedback:
- The option you are referring to is under tools > set compiler paths ctrl+6 right?
- The ini that needs to be modified SetCompilerPathsII.ini can be found in the folder 'Tools'
also if the ini is not there it needs to be created.
- I used the following settings

Code: Select all

"9.3 WL 1.08.0", "..\FreeBASIC-1.08.0-winlibs-gcc-9.3.0\fbc32.exe", "..\FreeBASIC-1.08.0-winlibs-gcc-9.3.0\fbc64.exe"
"5.2 WL 1.07.2", "..\FreeBASIC-1.07.2-gcc-5.2\fbc32.exe", "..\FreeBASIC-1.07.2-gcc-5.2\fbc64.exe"

Did get it to work however, regrettably, the current combined package of fbc (64 + 32 bits windows)
does not contain WinFormsX and Afx, how ever the method you suggested does allow for some flexibility.
Never the less I will sit back a while and wait for Paul to update the complete package.

I can see in this thread that there are still some kinks that need ironing out:
viewtopic.php?f=17&t=29421

[deltarho[1859]]

Hi Paul, you are the boss, but if I were you, I'd bundle 9.3SJLJ and 5.2. Of course, with just 9.3SJLJ it is easy enough to add 5.2, but I can imagine some members 'up in arms' at the extra work and some will have sleepless nights at the thought of using 9.3SJLJ.

[deltarho[1859]]

Did get it to work however

Well done.

You can get 1.08.0/5.2 here. 5.2, BTW, is not WL (WinLibs).

Afx.zip

I don't use WinFormsX.

The kinks with 1.08 are primarily graphics oriented. I am not into graphics coding and have been using fbc 1.08 for a while now without issues. If I published any of my graphics code, it would be treated as a source of entertainment.

[thrive4]

You can get 1.08.0/5.2 here. 5.2, BTW, is not WL (WinLibs).
Afx.zip

Thank you.
Bye the bye forget to mention kudos for writing SetCompilerPaths
I can imagine it being quite useful in specific scenarios.

[deltarho[1859]]

I am biased but I find SetCompilerSwitchesII even more useful. This is my current setup:

That saves going into Options>Environment Options...>Compiler Setup and doing any typing.

The above gives me '-exx -fpu sse -arch 686 -gen gcc -Wc -O2'. The '-fpu sse' is hard wired.

This is the ini file:

Code: Select all

"-gen gas"
"-gen gas64"
"-gen gcc"
"-gen gcc -Wc -O1"
"-gen gcc -Wc -O2"
"-gen gcc -Wc -O3"
"-gen gcc -Wc -Os"
"-gen gcc -Wc -Ofast"

Needless to say, you can add/remove switches.

Added: The above plugins were written using WinFBX and are DPI aware. The early versions were not DPI aware. Paul has a 4K monitor and had to use a magnifying glass to use them.

[xbgtc]

Question:

Why is F5 build and execute and Ctrl+Shift+F5 Quick Run?

Quick run should be F5 as that is the most used thing. :)

[Josep Roca]

> Quick run should be F5 as that is the most used thing. :)

Not by everybody. I never use it.

[xbgtc]

> Not by everybody. I never use it.

So how do you test code then?

[Josep Roca]

With build and execute (F5). If you don't recompile the code, how are you going to test the changes that you make?

[xbgtc]

Ok now i'm confused.

I test the code as stated in my first post - Ctrl+Shift+F5 BUT..

Why press three keys when you can press one? eg like FBIDE and just hit F5 for quick run.

I'm assuming "Quick Run" is what you do to test code because somehow it's better/more efficient? else why have it? afterall it IS called "quick run".

F5 compiles the exe but quick run has a temp exe so what really is the difference? apart from the temp exe being deleted after prog ends.

[Josep Roca]

> Why press three keys when you can press one? eg like FBIDE and just hit F5 for quick run.

Because F5 is already assigned to the Build and execute's option, that both the author and other users use more frequently. It is an editor for Windows, and Windows' programmers use more often a GUI that the console.

[xbgtc]

Ohh ok i think i get you now. The author and other windows coders want the EXE for some reason. If that is correct then i now understand.

[caseih]

The author and other windows coders want the EXE for some reason.

Getting an EXE is the whole point of the exercise! How would you quick run anything without the EXE?