Setting gcc compiler for WinFBE

[deltarho[1859]]

I have good news. Paul Squires, author of WinFBE, very kindly modified WinFBE to reload the ini file before a compilation. This means that we can use a build changing application whilst WinFBE is open making it an ideal candidate for being a WinFBE tool. Theoretically then, as my application stands, we could do 4x32-bit and 4x64-bit compilations without closing WinFBE.

First thing to do is to go to this link and download the rar file. On unpacking we get revised WinFBE32.exe and WinFBE.64.exe. The next step is to rename the existing binaries in the WinFBE_Suite folder to, say, WinnFBE32old.exe and WinFBE64old.exe and then drop the new binaries next to them.

I have completely rewritten SetGCCforWinFBE and called it SetCompilerPaths. There is no mention of WinFBE in the name because the same tool will be used for poseidonFB.

NOTE: Original SetCompilerPaths would accommodate up to four pairs of compiler paths - it will now accommodate up to six. (10 Sept 2019)

Download: SetCompilerPaths.zip

Unpack and drop into the UserTools folder.

Now run WinFBE32 or WinFBE64, whichever you use, navigate to Options>Environment Options...>Compiler Setup and make a note of the two compiler paths; which should read '.\FreeBASIC-1.06.0\fbc32.exe' and '.\FreeBASIC-1.06.0\fbc64.exe'.

Now create SetCompilerPaths.ini along the following lines:

Code: Select all

"WinFBE", "E:\Downloads\WinFBE_Suite\Settings\WinFBE.ini"
"5.2", "C:\Program Files (x86)\FreeBASIC\fbc.exe", "E:\Downloads\FreeBASIC-1.07.0-win64\fbc.exe"
"8.1", ".\FreeBASIC-1.06.0\fbc32.exe", ".\FreeBASIC-1.06.0\fbc64.exe"

The first string is simply "WinFBE" and the second string is your full path to WinFBE.ini.

The next three strings are a description followed by a 32-bit path and a 64-bit path got from the 1.07 installed version of fbc and the standalone version respectively.

The last three strings are "8.1", the gcc version used by WinFBE, followed by the two paths you noted earlier.

DO NOT finalize the ini file with an ENTER.

Now put SetCompilerPaths.ini into the UserTools folder.

Now to crate a tool.

Go to Tools>User Tools... to open the User Tools form.

Click on 'Insert' and type Set Compiler Paths into the 'Tool Name:' edit box. This will populate the list on the left hand side as well.

Now type .\UserTools\SetCompilerPaths.exe into the 'Command:' edit box.

Click on Ctrl and type 3 into the 'Key' edit box.

At the bottom of the form click on 'Display this item in the editor menu'

Now use the chevrons at the bottom left so that 'Set Compiler Paths' is at the bottom of the list.

Close the form with OK.

That's it. If you click on Tools in the menu you should see 'Set Compiler Paths Ctrl+3' and you are good to go.

If you click on that entry this should pop up.


You now have access to the official fbc build and 1.06/8.1 which can be changed 'on the fly'. I have been using 8.1 for a while now and found it to be fairly robust but if ever it proves problematic then we can switch to the official build 'at the drop of a hat'.

You now have two empty slots to add further builds - good luck on that one.

[PaulSquires]

I have to re-post updated EXE's when I get home today. It looks like the re-loading of the config file causes the THEME data to duplicate each time the compile process is initiated. As you can imagine, the size of the config file then grows bigger very quickly. I have the code fixed but I can't upload it to the server until a little later today. I will post here again when it's ready to be downloaded.

[PaulSquires]

I have to re-post updated EXE's when I get home today. It looks like the re-loading of the config file causes the THEME data to duplicate each time the compile process is initiated. As you can imagine, the size of the config file then grows bigger very quickly. I have the code fixed but I can't upload it to the server until a little later today. I will post here again when it's ready to be downloaded.

Okay, the newly corrected EXE's have now been updated and re-uploaded.

[deltarho[1859]]

Thanks Paul. I did notice that the previous versions were taking longer and longer to load but I couldn't figure out why. The ability to change builds quickly is not a must-have feature at the moment but it may well be in the not too distant future.

[deltarho[1859]]

The poseidonFB version got further developed than the WinFBE version and I forgot to transfer some 'smart code' to this version.

By 'smart code' I mean how SetCompilerPaths handles mismatches between the IDE's compiler path and the entries in SetCompilerPaths ini file.

Suppose SetCompilerPath.ini has entries A, B, C and D and C is in the IDE's ini file then SetCompilerPaths will open with C selected. However, if we removed C or changed C in SetCompilerPaths.ini then no radio button would be selected. We would then have no idea what was in the IDE's ini file. We could, of course, just make a selection but I find no radio button being selected a little disconcerting so SetCompilerPaths will take its first entry and put that into the iDE's ini file and show it as selected; which we can accept or choose another. SetCompilerPaths will tell us what it has done.

New version uploaded.

[deltarho[1859]]

With WinFBE, out of the box, the config file is read on opening and the compiler paths persist for the WinFBE session. On closing WinFBE the configuration, which may have been edited, such as changing fonts, is flushed to the drive and that will be used on the next WinFBE opening. Changing the compiler paths from within or without WinFBE would have no effect because the config file is not read again.

With the revised WinFBE, which reloads the config file before a compilation, if we change the compiler paths with SetCompilerPaths then when FBE closes our change will get saved to the config file; but only if a compilation has been executed. On WinFBE's next opening the compiler paths will be as last used.

If we choose a compiler path with SetCompilerPath, closed SetCompilerPaths and then closed WinFBE the next time WinFBE opens it would not use our last choice it will use the compiler path used on the last compilation, when the config file is reloaded.

If we wanted to ensure that WinFBE uses a particular compiler path on the next opening we do as follows: Invoke SetCompilerPaths and then close WinFBE. SetCompilerPaths will still be running. Choose a compiler path and then close SetCompilerPaths. Thats it!

This is not by design, it is the consequence of the revised WinFBE and the fact that SetCompilerPaths is run asynchronously.

So, we could have a default compiler path which will be used on WinFBE opening regardless of which compiler paths were used during the last WinFBE session.

[deltarho[1859]]

An upcoming fbc package may include four gcc versions. This will exhaust SetCompilerPaths and you may have some builds yourself so SetCompilerPaths has been updated to accommodate six pairs of compiler paths.

Version 1.02 uploaded.

[Arachnphilia]

An upcoming fbc package may include four gcc versions. This will exhaust SetCompilerPaths and you may have some builds yourself so SetCompilerPaths has been updated to accommodate six pairs of compiler paths.

Version 1.02 uploaded.

Hello David

First of all, many thanks for your little helper.
I installed it and configured it accordingly.
It works fine so far.
I don't like a little thing yet.
If I want not only "8.3" in the window, but more information like "FreeBasic 1.06.0 GCC 8.3", then the window width is not enough.
A variable window width, depending on the description, would be great.
Is that possible with you?

Arachnophilia

[deltarho[1859]]

Is that possible with you?

Of course it is. Welcome to the forums, by the way.

I'm a minimalist and don't want to have acres of unused white space.

"FreeBasic 1.06.0 GCC 8.3" is 24 characters long. On the other hand "1.06.0/8.3" is only 10 characters long without loss of information. The application clips into 13 characters giving us 3 spare on the short form.

Anyway leave the variable width aspect with me and I will see what I can come up. I'm busy with other things this afternoon so will have a look this evening.

[srvaldez]

thanks deltarho[1859]
btw, it was your initiative that sparked interest in more recent gcc toolchains, so kudos to you :-)

[deltarho[1859]]

@srvaldez

[deltarho[1859]]

@Arachnophilia

Here are three examples: A long description, your example and a short description.

A minimum width is imposed, third example, to stop form becoming too skinny and title being clipped. There is no maximum description length imposed so be careful.

Had the font been mono spaced it would have been easy - number of characters x font width - but I am using Tahoma 8 which is a proportional font. Fortunately there is a Windows API for almost everything and GetTextExtentPoint32 came to the rescue; well not quite - it was looking for a fight but lost.

Version 1.03 uploaded.

[deltarho[1859]]

This one is for members whose eyesight is not as good as it was.



Download: SetCompilerPathsL.zip

[Arachnphilia]

This one is for members whose eyesight is not as good as it was."

Hello David

Thank you so much for your adjustment.

But the last version is the best of all.... lol

Arachnophilia

[srvaldez]

@deltarho[1859]
try the following little test program, it's part of the test suite
my guess is that it will run on fb_gcc 8.3 and earlier, the same code runs OK on my Mac with Apple LLVM version 10.0.0 (clang-1000.11.45.5) FB from git 2019-20-08

Code: Select all

#ifndef __FBCUNIT_CONSOLE_BI_INCLUDE__
#define __FBCUNIT_CONSOLE_BI_INCLUDE__ 1

''  fbcunit - FreeBASIC Compiler Unit Testing Component
''	Copyright (C) 2017-2018 Jeffery R. Marshall (coder[at]execulink[dot]com)
''
''  License: GNU Lesser General Public License 
''           version 2.1 (or any later version) plus
''           linking exception, see license.txt

	declare sub crt_print_output _
		( _
			byref s as const string _
		) 

#endif

''  fbcunit - FreeBASIC Compiler Unit Testing Component
''	Copyright (C) 2017-2018 Jeffery R. Marshall (coder[at]execulink[dot]com)
''
''  License: GNU Lesser General Public License 
''           version 2.1 (or any later version) plus
''           linking exception, see license.txt

#include once "crt/stdio.bi"
''#include once "fbcunit_console.bi"

'' chng: written [jeffm]

''
sub crt_print_output _
	( _
		byref s as const string _
	) 

	fprintf( stdout, "%s", strptr(s) )

end sub

crt_print_output("123")

hello deltarho[1859]
after somewhat having recovered from my huge embarrassment, I did a bit of searching and found this bug report by TeeEmCee https://sourceforge.net/p/fbc/bugs/904/
it turns out that if you are compiling with the -gen gcc option then if you also add -Wc -Wno-format to the compile command, then the above compiles and runs ok
I hacked fbc.bas so that when compiling with the -gen gcc option it will add -Wno-format to the compile command, I then built FB with the work-in-progress gcc-10 and ran the tests, it failed a test that was trying to add an object to a library, I then upgraded the binutils to version 2.32 and ran the tests again, this time all tests passed, so there's hope for using the newer gcc toolchain.
btw, I left you a pm in the PB forum, in case you are interested in testing this version.