Build hell

[deltarho[1859]]

Of late I have been writing more GUI code and have several rc files one of which does nothing other than load a manifest; others load varying image files.

If I run some console code and I have an rc file mentioned in WinFBE's 'Additional compiler switches (optional):' then the compilation will fail. On the other hand, having removed the rc file, I may then run some code which needs it and the compilation fails again. One solution to this is to add to the 'Build Configurations...'. That saves me either deleting or adding. However, I will still get a failed compilation if I forget to choose the correct build for the current code. With WinFBE the default build is Win32 Console (Release) on opening.

With poseidonFB we have in the ini file [customCompilerOptions] the first entry being 'current=<Whatever>' where <Whatever> is the last build we used. This is better because I may be working on the same code for a few days and find the correct build on opening. However, if I write some test snippet then I may need a different build for that and I could fall foul with that.

What I would really like is a build association. Load xyz.bas and the associated build is chosen for us. With a new bas then an associated build could be saved on the first compilation. This will not be an easy task for either WinFBE or poseidonFB.

Along comes JK-IDE which does not have any fancy build lists and dialogs to negotiate. What we have is '#Compile'.

For example:

Code: Select all

#Compile exe console 32 /o "-gen gcc -Wc -O3 AES-RSA-ECDSA.rc"

I can now load a handful of bas files and give no consideration to build. JK-IDE doesn't remember what an associated build is it simply is not allowed to forget because the build is part of the source code. We could have '-exx' in there for a while and removed when we are happy to do so.

I have an application which I wrote some years ago which runs from the StartUp folder. It uses switches but they are not put into a command line but in an ini file. There are six possible switches and the current ini file is '/silent /displayonce /schedule: 180. It does some 'crunching' every 180 minutes, runs silently except on a Restart/Boot when is displays a TaskDialog. The other three switches are development related and not used in release code.

Both WinFBE and poseidonFB could look for an ini file separate to their current ini files which has nothing in it except switches and could be given precedent over any other builds mentioned in the IDEs. Association? Easy. We simply put a build ini file in the same directory as the bas. Chances are that I would cease to use either WinFBE's or poseidonFB's build systems and make sure every bas has a build ini. I have a folder for experimental code and test snippets. I could have a simple default build ini put there.

Any thoughts?

[PaulSquires]

Sounds like you're not using WinFBE's project capabilities?

[jj2007]

Along comes JK-IDE which does not have any fancy build lists and dialogs to negotiate. What we have is '#Compile'.

For example:

Code: Select all

#Compile exe console 32 /o "-gen gcc -Wc -O3 AES-RSA-ECDSA.rc"

That is simple and straightforward. Hell, you could even put your full code here, and somebody else could paste it in his JK-IDE, hit the build button, and yeah, it works, without long explanations of the exact "project" settings!

As Edsger Wybe Dijkstra once noted,

It is practically impossible to teach good programming to students that have had a prior exposure to Visual Studio: as potential programmers they are mentally mutilated beyond hope of regeneration.

[deltarho[1859]]

Hi Paul

I have never used the project facility in any IDE. I used JelyFish Pro from about 2004 and moved over to JK-IDE a few years ago but never got the urge to build a project.

I have just done a file search in my PBWin development folder and found only 7 bas files which exceed 100KB and only two exes which exceed 200KB. I tend to write small utilities and vary rarely use child windows; although I do have one which has two to call upon. So, I have never regarded myself as someone who needed a project facility. Over the years I have seen folk have issues with projects and decided I was probably well out of it.

I have also seen folk pull there hair out over debuggers. I don't use them and have my own ways of debugging including using Patrice Terrier's ZTrace with GUI code. I don't use visual designers either - I hand code and use GUIRuler developed form Gary Beene's gbRuler. I have used PBForms to knock out a starting position and then ripped out all the PBForms stuff and then continued tweaking by hand with GUIRuler thereafter. One trick I use is 'Dim as Long h' and have '+ h' after certain control's y position. Increasing h sees all those controls 'drop down' by the same amount at the next compilation/execution. You may laugh, but it works very well.

I am always up for new ideas and love to 'push the envelope' but in other respects I am a bit of a dinosaur.

Anyway, since you mention it I will have a look at WinFBE's project facility.

@jj2007

I noticed under Dijkstra's mug shot: Simplicity is prerequisite for reliability. Isn't it just. Some folk here tend to sprinkle their code, as with seasoning, with some of the more, how can I put it, esoteric FreeBASIC commands to the point where their code is hardly readable. No doubt they may save a few statements here or there but I suspect they may not be easily debugged if they do not do as intended. I would not touch, for example, 'Var' with a barge pole.<smile>

[PaulSquires]

If you are not using WinFBE's project functionality then there are a couple of things that might help:

Since v1.3.4 you can use the following two in code directives (ensure to start the line with the ' comment character)

'#CONSOLE ON
'#CONSOLE OFF

Since v1.5.9 you can specify a Resource file via a in code directive:

'#RESOURCE "resource.rc"

Obviously replace resource.rc with the name of your specific resource.

Hope that makes it a little easier. for your specific style of coding.

[deltarho[1859]]

Flaming heck! I was still on V1.5.6. I am usually quite good at keeping up to date.

Somehow I missed seeing '#CONSOLE.

I get caught out quite often with a chosen build using GUI and then introduce a Print statement for debugging forcing me to terminate ungracefully. I see now that I can have Win32 GUI build and '#CONSOLE ON will save my butt! Nice one. If I remember correctly you used an in code directive in JellyFish Pro for what is now 'Quick Run'.

'#RESOURCE "resource.rc" is an absolute gem for me and very much inline with the build association that I was rabbiting about. I don't have to keep adding to the 'Build Configurations...' which I was doing to eliminate the adding and subtracting to the 'Additional compiler option ...' edit box. For me that is a cracking addition.

Hope that makes it a little easier. for your specific style of coding.

Ha, ha - very diplomatic.

Thanks, Paul.