On Mon, Oct 6, 2008 at 11:57 PM, Enrico Tröger
<enrico.troeger@uvena.de> wrote:
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:
>
> > 1. 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.
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.
> > 2. 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