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.
This is useful for plugins to be able to subclass the ScintillaObject
and use its full GObject features. The Overview plugin is one known
plugin that needs this.
Also update scintilla_changes.patch by running update-scintilla.sh
script with patch application commented-out and generating a reverse
diff using `git -R`, and manually remove `a/` and `b/` prefixes from
the resulting diff so it can be used with update-scintilla.sh script.
geanyfunctions.h used to bring all function declarations, and some
plugins depend on this side effect instead of properly including
geanyplugin.h directly. So, reintroduce the behavior for
compatibility with those plugins.
- 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
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.
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.
Use the same variable style for simple interpolations ("$foo") than for
complex ones ("${foo}") instead of using the string style itself. This
gives a visual feedback for simple interpolations.
The (almost) black color of the inside of the bottleneck is a bit too high
contrast and doesn't fit the rest of the icon (the only black part of it).
Use the "lamp yellow" as the base and lower the L in HSL representation of
the color so it just looks as darker lamp material.
After making the bottleneck wider (by shifting the curve to the left), the
curve became flatter which looks strange. Make the curve a bit more round
in the middle.
Graphical applications on OS X are started using launchd and don't inherit
shell's environment variables so we don't get the PS1 value. Do the same
as the OS X terminal emulator which runs the shell as a login shell (and yes,
on OS X .bash_profile is read for shells started in the terminal application
instead of .bashrc).
On OS X Monospace 10 is too small (and using non-standard font).
As we already have a special OS X font for the editor, use this value
(having identical fonts both for the editor and VTE seems to be a
good default).
The argument quoting must be permissive (g_ascii_isspace() doesn't
handle '\v'), the program name to arguments separator must be fixed
to restrictive, and the leading spaces are somewhere between.
Also fixed the test program to check for exactly 2 arguments.