This restores the previous behavior as it has been on non-Windows
systems before.
Post-1.29 we will merge #1300 which implements run helper script support
for non-Windows systems more sophisticated.
Apparently using arguments instead of putting paths directly in the
script is enough for it to work on Windows, so use a simple script
instead of a program, so it's both shorter and easier to tune.
This removes all encoding issues from passing on a script to cmd.exe on
Windows, as it now uses proper wide character API there.
Not much changes on other OSes, but we don't create temporary scripts
anymore.
Move the tag manager implementation to src as it really is part of Geany
sources and start making the ctags directory structure similar to
the universal-ctags one.
In principle, the patch does
mv tagmanager/src src/tagmanager
mv tagmanager/ctags tagmanager/main
mv tagmanager ctags
plus corresponding Makefile.am and configure.ac updates.
Make each convenience library depend on the ones it requires, which is
pretty straightforward for us as they each only depend on a single
other one, avoiding any worry about double linking of static objects.
encodings.h had a pretty large GEANY_PRIVATE part so it's worthwhile to
separate that into its own header (as per HACKING). What's left is used by the
plugin API.
Since we build libgeany some ld flags were applied to libgeany only.
Some of them need to be applied to the main binary as well.
This fixes the problem that a sticky terminal window starts together
with geany.
autotools based build system uses only config.h. This file was lacking some
important defines. Rather than maintaining the defines in all build systems,
we can simply define in a specialized header that is included by all .c files
that use windows.h
Ubuntu's linker apparently has a bug when installing in /usr/local/lib,
as it is setup in such a way that makes libtool recognize it correctly
as a system path so doesn't add RPATH to our executable, but ld can't
find the library without an explicit ldconfig call (unlike when
installing in /usr/lib).
So, workaround this by explicitly calling ldconfig when installing in
/usr/local/lib -- and when our library is actually not found, to try
and avoid doing something unnecessary on working systems, like e.g.
Debian.
When mac integration or binary relocation are disabled, the compiled
object file contains no symbols because the guards in the source files
hide all code. On OS X there's a warning during compilation saying:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: .libs/libgeany.a(libgeany_la-prefix.o) has no symbols
If these features are disabled, don't compile the corresponding
sources to avoid the warnings.
Interestingly, waf compilation works without warnings - it appears
linking is done through g++ which doesn't produce these warnings.
Instead of processing a template C source in the build system, generate
a list to be included by the preprocessor.
This simplifies the build system code as it now only generates the list
and doesn't take care of processing the template. It incidentally
fixes build on systems with 4.2BSD sed (at least OSX and FreeBSD) as it
removes some offending sed code.
This makes it easier to define it consistently to what the compiler
and platform supports, and avoids having to include a special header
everywhere, which is some kind of a problem for separate libraries
like TagManager and especially Scintilla.
As we only use these macros from the source and not the headers, it
is fine for it to be defined to a configure-time check from the build
system.
Warning: Although Waf and Windows makefiles are updated they are not
tested an will probably required tuning.
The flags in this variables are used to tune the linker behavior on the
final libgeany (currently set the version information), so should only
used on really linked libraries, not Libtool helper libraries.
This prevents having to export those callbacks and put them in the
global namespace. Also, use inline shell script in Makefile.am instead
of a Python script which should be more portable (by default) and gets
rid of the helper script.
Checks if the compiler supports -fvisibility and the linker supports
-dynamic-list arguments and use them instead of hardcoding. The new
geany-lib.m4 also accomodates future use of Libtool versioning.
This will allow plugins to link against the core when accessing API
functions, now that the macro/struct/funcptr stuff is gone.
Also convert the helper libraries into Libtool helper libraries as
linking a shared library against static libraries is (apparently) not
portable.
Add rest of headers needed for declarations of all public API
functions. Add HAVE_PLUGINS define to geanyplugins.h since some headers
need this and it should always be valid for this header.
geanyfunctions.h left for source-level backwards compatibility for
plugins which might `#include` this header directly. I don't know why
they do it, but some Geany-Plugins do this.
Adds a new header `pluginexport.h` to put the macros in, could be
moved into an existing header (support.h?) by I didn't want to drag
a bunch of existing stuff into the source files for this one macro.
TagManager has relative include, this could be fixed by changing the
include directories for it if it's a problem. Mark the Scintilla
functions exported by re-declaring them in sciwrappers.c with the
attribute to avoid changing upstream Scintilla code.
Uses a Python script to generate a listing used by the linker to
determine which symbols to dynamically export. This provides finer
grained control of which symbols are dynamically exported, limiting
only to the ones needed for GtkBuilder signal connections.
The build system integration could probably be done a little cleaner.
g_spawn_async_with_pipes() under Windows has various drawbacks:
- There is no g_shell_parse_argv() for windows. It's not hard to write
one, but the command line recreated by mscvrt may be wrong.
- GLib converts the argument vector to UNICODE. For non-UTF8 arguments,
the result is often "Invalid string in argument vector at %d: %s:
Invalid byte sequence in conversion input" (YMMV). Our tools (make,
grep, gcc, ...) are "ANSI", so converting to UNICODE and then back
only causes problems.
- For various reasons, GLib uses an intermediate program to start
children (see gspawn-win32.c), with the side effect that the
grandchildren output (such as make -> gcc) is not captured.
- With non-blocking pipes, the g_io_add_watch() callbacks are never
invoked, while with blocking pipes, g_io_channel_read_line() blocks.
- Some smaller problems, explained in spawn.c as inline comments.
The spawn module tries to fix these problems, and to provide easier
APIs, which guarantee that the callbacks will synchronized as expected,
and g_io_channel_read_line() will not be required, since even under
Unix, it may buffer lines of unlimited length.
This initial commit only adds the module source and header files, and
includes it in the various build systems.
You can see PR 274 for a long discussion about the module.
We have to disable quartz accelerator handling because otherwise
accelerators are performed also from other windows than the main
Geany editor (e.g. Ctrl+V with find dialog open performs the keybinding
Ctrl+V and inserts the text to the editor).
OS X applications have an extra menu entry to the left of the File menu -
an "application menu". This menu usually contains About, Preferences,
Quit. Many users, however, may be used to Geany from other platforms
and expect Preferences to be under the Edit menu so leave them there.
Quit and About are rarely used and the application menu is the place where
they are supposed to be - move these entries from other Geany menus there
and hide them in the affected menus (the quit entry is inserted automatically,
we just need to hide it from File).
Also tell OS X the Help menu is dedicated to help (we get search in
menu entries by name for free thanks to this).
The global menu should refresh automatically based on user actions.
Unfortunately this is not the case when gtk_menu_reorder_child()
is used because it does not emit any signals so the gtk-mac-integration
library doesn't see this call. Refresh the menu manually after calling
this function.
This patch adds the gtk-mac-integration library and uses it to
adjust various paths in Geany to point it inside the app bundle
if Geany runs from inside the bundle.
It adds the utils_resource_dir() utility function to return
correct directories for various kinds of resources for all supported
operating systems. Using this function the patch adjusts all Geany
resource, plugin, icon, doc, and locale paths.
Strict dependency on fnmatch was removed in 52076d19e8fe7ab41ebc92928e.
We still have an optional dependency on it from CTags, but I don't
think we use this code, and anyways the checks we had for the optional
path to be taken were incorrect, so it was never actually used.
So, drop the dependency on libibrety for Windows builds, and fix the
remaining checks for an optional fnmatch so if it is found it can
actually be used.
This is a mega-commit - because most of it had to be done in one go
otherwise some commits would fail to compile - that attempts to fix a
few problems with Geany's includes as well as various other related
cleanups. After this change it's easier to use includes and there's
little worry about which order things are included in or who includes
what.
Overview of changes:
* Include config.h at the start of each source file if HAVE_CONFIG_H
is defined (and never in headers).
* Go through each source file and make the includes section generally
like this:
- Always config.h first as above
- Then if the file has a header with the same name, include that
- Then include in alphabetical order each other internal/geany header.
- Then include standard headers
- Then include non-standard system headers
- Then include GLib/GTK+ related stuff
* Doing as above makes it easier to find implicit header include
dependencies and it exposed quite a few weird problems with includes
or forward declarations, fix those.
* Make geany.h contain not much besides some defines.
- Add a little header file "app.h" for GeanyApp and move it there
- Move "app" global to new "app.h" file
- Move "ignore_callback" global to "callbacks.h"
- Move "geany_object" global to "geanyobject.h"
* Add an include in "geany.h" for "app.h" since GeanyApp used to be
defined there and some plugins included this header to access
GeanyApp.
* Include "gtkcompat.h" everywhere instead of gtk/gtk.h so that
everywhere sees the same definitions (not a problem in practice AFAIK
so this could be changed back if better that way.
* Remove forward declarations from previous commits as some people
apparently consider this bad style, despite that it reduces inter-
header dependencies.
TODO:
* As always, to test on win32
* As always, to test with not Autotools
* Test plugins better, both builtin and geany-plugins, likely API/ABI bump
* Test with various defines/flags that may change what is included
* win32.[ch] not really touched since I couldn't test
This is for work on making the files scannable by GObject-Introspection
but is still useful otherwise (even fixes a FIXME in the comments). I
made this by using a simple GNU Make file and trying to compile the
sources each on their own without all the build system infrastructure.
* Add keybindingsprivate.h file to hold private GeanyKeyGroup structure
and remove it from the GEANY_PRIVATE guard in keybindings.h.
* Move private members that were guarded by GEANY_PRIVATE from
GeanyFiletypes to GeanyFiletypesPrivate and remove guarded build.h
include.
* Move private members that were guarded by GEANY_PRIVATE from
GeanyProject to GeanyProjectPrivate.
Use the GtkComboBoxText API and the GtkComboBoxEntry replacement API
and map those to the old equivalents if not available.
This changes the type exposed by ui_combo_box_add_to_history() from
GtkComboBoxEntry to either GtkComboBox (under GTK2) or GtkComboBoxText
(under GTK3). This should not be too much of an issue since
GtkComboBoxEntry and GtkComboBoxtext are subclasses of GtkComboBox,
but this will still emit warnings when when the calling code passes
a GtkComboBoxEntry pointer to ui_combo_box_add_to_history().
However, this requires the calling code to use the same mapping as we
do (GtkComboBoxText = GtkComboBox on GTK2, even on 2.24), or things
will blow and it'll be hard to understand why. This wouldn't be an
issue if the calling code includes our gtkcompat.h header everywhere
it deals with combo boxes, which will be the case if it includes the
Geany headers everywhere but probably won't otherwise. Oh dear.
A possible kind of workaround may be for ui_combo_box_add_to_history()
to do type-checking on its argument and use the actually correct API
for that type.
We explicitly use GModule's .pc since 7b2f0fe, and it provides the
appropriate flag: we don't need to add it ourselves anymore. Moreover,
since this flag is not needed (nor available) on all platforms (e.g.
Windows or MacOS X), it is safer to let GModule deal with adding it
anyway.
Split ctags and tagmanager sources, as follows:
tagmanager/ctags: the parsers, more or less upstream CTags;
tagmanager/mio: local MIO library copy;
tagmanager/src: actual tagmanager sources.
