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
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
