[Geany-Devel] [FT-plugins] Proposed "Features"

[Matthew Brush]

On 2016-08-31 09:57 PM, Thomas Martitz wrote:
> Am 01.09.2016 um 02:50 schrieb Matthew Brush:
>>
>> I don't think they'll usually require a "build system" per se, but
>> they definitively need to be told how to compile the code where
>> applicable.
>>
>> For libpython, I don't think it needs any flags. For libvala IIRC and
>> libclang (if not using compile_commands.json) they require the `argv`
>> you'd pass to the compiler itself. It may very well be possible for
>> ft-plugins using libraries with the `argv` approach to just grab the
>> compile command from Geany's build commands and convert it back into
>> an `argv` array or something.
>
> Not sure how you use Geany, but I never set the cc command line for
> individual files. I never type CFLAGS or CXXFLAGS into Geany's build
> settings.
>

Yeah, that's why the absolute base functionality provided must always 
exist. I'd probably be more willing to do a little setup for actual 
projects if there was a benefit though.

> Actually most of the time I don't set up the build system at all and
> alt-tab to a terminal where I use my employers crazy build system which
> uses make under the hood but can't be used from within Geany properly.
>

This use-case should continue to be the default supported one.

> Then, some other time (e.g. for compiling Geany) I sometimes use the
> make command. But obviously Geany only knows that running "make" builds
> something. It doesn't have enough information to construct a compiler
> command line.
>

Indeed. To provide "real IDE" features and project requires more than 
what Geany provides out of the box. I haven't really proposed a design 
for this, so as it stands ft-plugins would have to provide some means 
(ex. advanced project support, compile_commands.json, custom GUI, etc) 
to get this info from the user.

> Some other time again I'm working on cross compiled projects. Here I
> again don't usually use Geany's build system support, but if I would it
> would run (e.g.) avr-gcc, with avr-gcc specific compiler flags, not
> known to clang (is there even a clang port for avr? I don't think so).
>

For an example libclang plugin, clang would have to be able to parse the 
source. It would require valid C/C++/Obj-C code for sure (though IIRC 
some of the helper functions for IDEs/tools handle partial source files 
or simple lexing to handle on-the-fly IDE highlighting and such).

> So a ft-plugin that only works if a file can be compiled is likely to be
> unworkable for me. It needs to deal with when it can't build the source
> files (either because of lacking *FLAGS or because the target isn't
> supported by the compiler). Likewise, if a ft-plugin only supports x86
> (i.e. is arch dependent) it's not interesting to me.
>

For actual projects you would work on for a while, it would be worth 
setting up some meta-stuff.

> There is also the possibility that the file I'm editing is not compiled
> at all with the current build settings, e.g. win32.c.
>
> How would you deal with all that? The ft-plugin has to do something in
> such situations doesnt it?
>

Fallback to the current features, ideally.

Cheers,
Matthew Brush