[Geany] Generalisation of build system

[Enrico Tröger]

On Fri, 3 Oct 2008 15:40:23 +0100, Nick Treleaven
<nick.treleaven at btinternet.com> wrote:

> On Fri, 3 Oct 2008 17:32:26 +1000
> "Lex Trotman" <elextr at 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.

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.


> > 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).


> > 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.

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.

> ...
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/users/attachments/20081006/b9ed6ce9/attachment.pgp>