[Geany] Generalisation of build system

Tue Oct 7 01:42:04 UTC 2008

On Mon, Oct 6, 2008 at 11:57 PM, Enrico Tröger <enrico.troeger at uvena.de>wrote:

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

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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/users/attachments/20081007/fd94039e/attachment.html>