jj2007 wrote:- kick out all "toolchains" except one
Counterproductive. People that don't take part in development shouldn't tell people that actually do something to stop.
- define an absolutely clear path structure defining non-ambiguously where FB.exe expects, relative to its own location, the various libraries and header files
Fine. I would widen it to intermediate user documentation. How do I compile and install my own FB. This is important because the intermediate users are important for (1) testing with quality, detail feedback (2) the occasional patch (3) a stage between ordinary users and developers. A percentage might become devels one day.
Around 2007 I had the same issue with FPC. Many newer users wanted to take the next step, but lacked the resources. This was a problem because due to a relative slow release cycle people were reporting bugs for a version that was quite old. So I wrote this the FPC buildfaq
to encourage new users to track development closer.
It also describes into detail how the compiler finds it files, something to keep in mind for the "default parameters" question further down.
- adopt one IDE (and I know this would hurt the authors of several other good IDEs)
Don't set anything in stone forever. That rewards short term thinking too much. Also the problem is that the most advanced IDEs are usually bound to one platform (and usually that means Windows).
But actually having a default option delivered with the installation might be a good thing. It gives the user the feeling of completeness. But I'd make it the choice per major development cycle per target. That is a better tradeoff between rewarding short term development goals (an usable IDE now) and long term. Targets are typically something like Dos, Windows, OS X and general *nix.
It took nearly ten years
for the logic choice, lazarus, to become the actual default choice for users. (lazarus started 1998, and the bulk of the users migrated only in the 2005-2007 timeframe. Lazarus acquired a win32 native GUI in late 2003, and that was only released formally in 2005, before it was GTK only, this was probably a large part of the shift in user preferences)
- or adopt one default set of command line options that works with everything*).
We use a configuration file, written by the (platform specific) installer. If you don't want the compiler to be soiled by state, consider a frontend binary that does this (reading the configfile with parameters and then call the real compiler).
I see the objection "so how, for example, should the compiler know whether it's a console or a GUI application?". My IDE counts the number of keywords in the source that are console-specific and compares it to the GUI-specific ones. If that fails (on very rare occasions), you can override it with an option in the source, like 'OPT_Susy console. Never had a problem with that in the last ten years.
The problem is that the console vs gui is not a black-white difference. Even on Windows GUI apps can open consoles. Basically on Windows you can "just" set a bit to not open a console. You can even start as a console app, and then become gui only. Vice versa (first gui and then console) is more difficult, since the terminal would be only temporary (*)
On *nix, the apps themselves must actively close the console to become "gui only". But many just leave the console open for debug output (with the proper switch)
(*) note to self. Make some examples of such apps.