There is no need to do it differently as Linux here, and it confuses the
autotools based compilation of geany-plugins which installs to libdir/geany
unconditionally.
On OS X signallist.i is always rebuilt because waf looks for it in the build
tree but generates it inside the source tree for some reason so it's
always missing in the build tree. Set the target explicitly to the
build tree to fix the problem.
Similarly, set the target for geany.html to the build tree. Thanks to this
waf also creates the 'doc' directory in the build tree which is otherwise
missing and the cwd command fails for this reason (e.g. when the
_build_ directory is removed).
These two task generators are the only ones that don't use the 'features'
parameter - the features in the other task generators should already
handle the source/build tree problems for us (see the Waf Book section
6.3.3. Nodes, tasks, and task generators).
When doing "./waf install" and some source files are modified
so they need to be rebuilt, the build and install phase can be
interleaved so one thread is still performing build while other
thread is already performing install tasks.
This appears to be a problem (at least on OS X) when some of
the Geany plugins are still being built and libgeany is already
being installed in parallel.
Create a separate group for the install phase to eliminate the
problem.
- libgeany install dir was wrong on win32
- comdlg32 is required
- more headers need to be installed
- -fPIC is required on some platforms
- LINKFLAGS_cprogram now have to be applied to libgeany.dll
In Waf, we need to add the new flags to CFLAGS *and* CXXFLAGS otherwise
the Scintilla build would break.
To keep it more reabable, we first populate a temporary list
geany_symbol_flags which is then added to CFLAGS and CXXFLAGS.
Concerning the quote FIXME: no further qoting is necessary here.
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 32x32 size can be created by downsampling the 48x48
icon by gtk at runtime but the result will be worse than
doing the same directly from the svg icon (48->32
conversion means downsampling by 1.5 which can introduce
some moire artifacts and loss of information). Since
32x32 are quite commonly used, it makes sense to ship
this icon size with Geany.
The png files have been optimized by pngoptim to remove
metadata and compress the icon better.
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.
The ant_glob() function doesn't return a list of strings but rather
a list of waflib.Node.Nod3 objects. These print as paths so build
works but apparently confuse waf which thinks the files have
changed every time the waf command is performed.
Relinking scintilla and geany on every waf invocation is especially
problemmatic during "sudo waf install" where scintilla and geany
binaries get owned by the root user. This isn't a big problem on Linux
but on OS X this prevents subsequent waf calls to update the
binaries and the build fails.
To fix the issue, just convert the waflib.Node.Nod3 objects
to relative (string) paths.
Make go one of the builtin filetypes, add the parser and update the related
source and config files. While there, remove Rust from [Groups] in
filetype_extensions.conf because it's already a builtin filetype as well.
The parser itself is stolen from the fishman/ctags repo.
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.
In addition, rename all functions, parameters, comments etc. mentioning
work_object and remove unnecessary parameters of various functions.
Delete dead code paths.
Also move common functions like tm_get_real_path() from tm_work_object to
tm_source_file.
In addition, this patch defines the GEANY_PRIVATE macro for the tag
manager library where it wasn't defined before, removes 2 tag manager
headers from distribution as they are not needed by plugins and
in the tag manager changes the docstrings to ordinary comments for
private definitions.
This is cleaner than searching for rst2html and rst2html.py since Waf
offers the API for this and this change enables Windows support.
While at it, add binary name 'rst2html2' for ArchLinux support.
