On Mon, Oct 6, 2008 at 11:57 PM, Enrico Tröger enrico.troeger@uvena.dewrote:
On Fri, 3 Oct 2008 15:40:23 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 3 Oct 2008 17:32:26 +1000 "Lex Trotman" elextr@gmail.com wrote:
- Compile, build and run are filetype specific and get their
command from the filetype config (question what is runcmd2 config for?)
It's only used for the LaTeX filetype so you can view a .dvi and view .pdf files.
And should be removed sometime in the future... Bad enough I actually introduced these, we really should remove them. Probably Frank and other LaTeX users will complain but we already have a GeanyLatex plugin which could replace some of the functionality to remove. But that's another topic.
I was looking to keep the changes small enough that I can help with implementation, so I didn't (and still don't) want to touch that bit.
- Make all. Make Object and Make custom are not file specific but
add different targets to the make command stored in preferences or default a. since Make Object needs to find a target name it uses the current file name + '.o' (seems to be hard coded irrespective of platform) b. 'all' is hard coded
I know some windows compilers use .obj, but as you said it's currently hard coded. Also perhaps 'make' would be a more flexible default than 'make all'.
Long time ago, something about 3 years, I thought the default target when executing only 'make' was the target 'all', so I added the menu item 'Make all' for convenience. But obviously this was wrong. The default target is the first one found in the Makefile. I wanted to change the hardcoded 'make all' for the last two years but I never ever got to it :(. And since we already announced the string freeze for Geany 0.15, it has to wait again (or replaced by configurable commands or whatever).
These modifications need some time to sort out the best solution and to code so I wouldn't suggest quickly forcing changes into the 0.15 release. What I will do over the next few days is to write a proposed Build System section for the manual which can be discussed, agreed and act as a specification.
That just leaves the file type specific build and run commands to consider.
The file type dependent behavior is correct for single file type systems where there is no build system.
However consider developing a 'c' extension to python, the compile/build should indeed be dependent on the c file open for editing, but the run command is the python script that imports and tests my c extension, and that command should not be stored against the c file type. This potential conflict exists for any mixed language system. (No I wouldn't remember to switch to the python file before running)
But this is not what the Build system was designed for. It should provide an easy and basic way to compile/build files, mainly for testing purposes while developing (simple) code.
Your test case is something more advanced, IMO.
But the problem is that I still have to invoke the builder from Geany, or I lose the ability to have Geany parse the compile output and jump to the source file where the error occurred. It is easy to invoke a builder in another xterm, but then I have to manually deduce the compile error locations, a loss of functionality for bigger systems just when it is needed :-(.
Although Geany is small and lightweight, that shouldn't stop it being used on big programs. In fact to give an an unsolicited complement, it is the very lightness and flexibility of Geany that make it usable in these situations. Other IDEs such as Anjuta and Kdevelop may provide more support in some areas but are too tightly tied to their way of doing things, making it difficult to support other tools and especially to support cross platform development unless you do it their way. In fact Kdevelop 3 can't even configure the make command, their solution is to write a makefile calling the other builder, but just try to get that to pass targets and options from the command line to the other builder!! So the intention is to allow Geany to be used with our big/complex/different applications while not imposing any restrictions on simple uses. A large/complex project can afford to spend time configuring commands and projects but sane usefull defaults should be available out of the box for simple uses. UMMM I'll climb down off my soap box now :-).
Please note I'm not intending to criticise past design decisions, all tools evolve over time to address more and different uses, and no one can forsee where future evolution will go.
Nevertheless, things can be improved but in any way, I want to keep a subset of the current functionality which enables users to quickly compile and test short pieces of code.
The intention is that the default configurations should do just that, after all, I also use it for simple programs as well ;-).
... I think broadly I agree with these ideas, thanks for taking the time to look at this. These changes will be quite substantial, I guess they could be done in an SVN branch.
Finally one other suggestion, while looking for where the filetype specific commands are set, I had to look in the code because the menu "set includes and arguments" was not obvious, perhaps it should be changed to "set build & run commands" or something similar.
Yes, something like "Configure Commands".
Let's change this after 0.15, translators probably won't like it to see changed strings again :).
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Cheers Lex
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany