[Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin

[Lex Trotman]

Hi again,

<snip>

>> Sigh, this isn't your fault, but I have problems with installing
>> unknown software to system directories and plugins autofools is broken
>> WRT installing to a non-standard prefix, waf build works if your
>> plugin had a wscript.
>>
>
> And I dislike using non-standard solutions (as standard I consider
> autotools, despite all its drawbacks), so we have a nice deadlock here
> :-).

Your prerogative, but it means that I won't test your plugin.

>

>> In another post on this thread you complain about IDEs that limit how
>> projects work (agree completely BTW), but you would restrict Geany to
>> only one build tool? ;-)
>
> Not only one, but only _the_ one the user provides. The dialog should
> look this way:
>
> Build command: edit_box
> Base directory: edit_box

Ummmm, thats what the command and working directory columns are

>
> so if I provide something like
>
> Build command: make
> Base directory: /home/techet/projects/geany
>
> it would run:
>
> cd /home/techet/projects/geany

Unix only, not portable, thats why the working directory isn't done that way.

> make

So you don't want make object or make target???

If you do have them then you need to be able to define where the
arguments and options go on each of these build commands.

Builders other than make require options and arguments in different
orders, thats what started the whole build system update in the first
place, the arguments Geany 0.18 pasted didn't work for some builders.

So the dialog allows the whole command to be configured, and since you
are not running make any more, it allows the menu label to be changed
to say what you are doing.

>
> (+ there should be a possibility to use the variables like %e, %f, ...)
>
>>
>> The update to the build system is to support running any commands,
>> make,nmake,  waf, scons, cmake, ant, bjam, my_favourite_shell_script
>
> But the current build system (and the one present in 0.18) already
> _can_ do that, see above. And yes, at work I use my own script that
> based on the current file detects the current subsystem, runs other
> necessary scripts and starts the build of the subsystem. Why do we
> need the special cases as above?

See above.

>
>> etc so the "Non-filetype commands" can't be called "make commands"
>> anymore, and unfortunately the name "Build" has been appropriated for
>> link, other suggestions welcome though, but there aren't many commonly
>> understood terms about.
>>
>> It is also to allow the commands to be configured differently for
>> different projects, since, if you use software from lots of sources,
>> you get lots of build systems.
>
> For this I would suggest just a list of build_command/base_directory
> pairs that the user can save, load and delete.
>

Thats exactly what the project preferences build tab is.


>> At university I was using SciTE as
>>> the editor for everything and it was just fine (yes, and SciTE calls
>>> the thing "session" ;-). But for projects with thousands of source
>>> files and hundreds of directories it's just no fun, believe me.
>>
>> I can believe its not good at this. Is anything?
>
> geany + gproject ;-)

As we say here, this has been a paid political advertisement :-)

>
> What you need is to be able to quickly navigate between the files. For
> this reason I had to fix the tab switching bug and introduced
> header/source swapping.
>
> You need to be able to filter out as many extra files as possible
> (that's why only the files that match the pattern you provide are
> included in the project).
>
> You need fast searches in files. grep is pretty fast when you restrict
> it only to the source files. So the plugin uses the patterns you
> provide as a definition of the files belonging to the project and
> automatically adds the restrictions as an extra potion in the find in
> files dialog; e.g.
>
> --include=*.c --include=*.h
>
> The first search is always slow, because the project files have to be
> read from the disk. But the subsequent searches are pretty fast
> because the files are already cached by the OS. So searching for
> "torvalds" in the whole linux tree (only *.c and *.h files) takes just
> about 3 seconds.
>
> Then you need to be able to quickly find a file by name. In my plugin
> you can use an arbitrary glob pattern for that (the leading and
> trailing * are inserted for you so you just need to type a part of the
> file name).
>
> Also building the file tree should be as fast as possible. Again, this
> is relatively slow when you open the project for the first time, but
> any subsequent project opening is very fast (2 seconds for linux
> kernel, from this only about 0.5 second creating the file tree).
>
> Also there is also a feature that the selected file in the file tree
> automatically follows the currently opened file - so the tree
> automatically expands and locates the current file for you - this
> simplifies locating the current subsystem.
>
> And most importantly, the editor should be relatively sane and not to
> try to reparse the whole project every time you edit or save something
> - 100pct CPU usage is guaranteed all the time in this case.
>
> The current geany attempt to project is not good enough - I can't open
> 10000 files. On the other hand, geany doesn't provide a good enough
> way how to quickly access non-opened files, which is the purpose of my
> plugin.
>

As I said before, I'm not saying there is anything wrong with your
plugin, I can see the need.


>> OTOH I don't see why you want to take out the current project system,
>> it shouldn't get in your way, but if it does ask about changes, and
>> having a built in simple system for simple uses is important.  Keeping
>> simple things simple is a reason for further work on the build system
>> so your simple needs are met by default, but my complicated ones are
>> possible with a plugin. (oh and your complicated one for killing
>> builds :) )
>
> I absolutely don't wish to replace the current system - it's OK for
> simple use cases (the reason why I wanted to make it plugin was to
> make absolutely sure that the API contains all the required
> functionality for whatever project management plugin). I only wish to
> create an alternative project management that works well with huge
> projects. All I want is that I can do the same things as the current
> session-project does - which I can't now (and also if there was just
> me, I would rename the current project to "session" and gproject to
> "project" :-)
>
> And my plugin keeps simple things simple - I hope one day in the
> future some brave man will actually test it to see...
>

See why not above.

>>>
>>> (I'm pretty curious how you're going to kill the remote builds.)
>>
>> I won't, the default will be to kill the head process like now, but
>
> Like now? There is nothing like that now AFAIK.

Sorry to confuse, I meant like the execute menu items do now.

Cheers
Lex

>
> Jiri
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>