| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* especially to improve building on FreeBSD 11
* We need GNU Make, yet alone because Scintilla/Scinterm
needs it. We now document that dependency and added
an Autoconf check from the autoconf-archive.
We make sure that the build process is invoked with GNU make
by generating only GNUmakefiles.
The Makefile.am files have not been renamed, so this
change can be rolled back easily.
* Some GNU-Make-specific autoreconf warnings have still been
resolved. But not all of them, as this would have been
unelegant and we need GNU Make anyway.
* Declare ACLOCAL_AMFLAGS to appease autoreconf
* Added an explicit check for C++11 from the autoconf-archives.
In general we should support building with every C++11 compiler
that is sufficiently GNU-like.
* Do not use `sed` for inplace editing, as different sed-implementations
have mutually incompatible syntax for this.
Instead of declaring and checking a dependency on GNU sed,
we simply use SciTECO for the editing task.
This improves code portability on BSDs.
* Similarily, BSD/POSIX `cmp` is supported now.
This fixes the test suite on BSD without declaring a
dependency on the GNU coreutils.
* Simplified sciteco-wrapper generation.
|
|
performance issues with memory measurements
* Fixed build problems on Windows
* g_slice on Windows has been shown to be of little use either
and it does not work well with the GetProcessMemoryInfo()
measurements.
Also, it brings the same problem as on Glibc: Not even command-line
termination returns the memory to the OS.
Therefore, we don't use g_slice at all and commented on it.
* The custom Linux and Windows memory measurement approaches
have been shown to be inefficient.
As a workaround, scripts disable memory limiting.
* A better approach -- but it will only work on Glibc -- might
be to hook into malloc(), realloc() and free() globally
and use the malloc_usable_size() of a heap object for
memory measurements. This will be relatively precise and cheap.
* We still need the "Object" base class in order to measure
memory usage as a fallback approach.
|
|
* we were basing the glib allocators on throwing std::bad_alloc just like
the C++ operators. However, this always was unsafe since we were throwing
exceptions across plain-C frames (Glib).
Also, the memory vtable has been deprecated in Glib, resulting in
ugly warnings.
* Instead, we now let the C++ new/delete operators work like Glib
by basing them on g_malloc/g_slice.
This means they will assert and the application will terminate
abnormally in case of OOM. OOMs cannot be handled properly anyway, so it is
more important to have a good memory limiting mechanism.
* Memory limiting has been completely revised.
Instead of approximating undo stack sizes using virtual methods
(which is unprecise and comes with a performance penalty),
we now use a common base class SciTECO::Object to count the memory
required by all objects allocated within SciTECO.
This is less precise than using global replacement new/deletes
which would allow us to control allocations in all C++ code including
Scintilla, but they are only supported as of C++14 (GCC 5) and adding compile-time
checks would be cumbersome.
In any case, we're missing Glib allocations (esp. strings).
* As a platform-specific extension, on Linux/glibc we use mallinfo()
to count the exact memory usage of the process.
On Windows, we use GetProcessMemoryInfo() -- the latter implementation
is currently UNTESTED.
* We use g_malloc() for new/delete operators when there is
malloc_trim() since g_slice does not free heap chunks properly
(probably does its own mmap()ing), rendering malloc_trim() ineffective.
We've also benchmarked g_slice on Linux/glib (malloc_trim() shouldn't
be available elsewhere) and found that it brings no significant
performance benefit.
On all other platforms, we use g_slice since it is assumed
that it at least does not hurt.
The new g_slice based allocators should be tested on MSVCRT
since I assume that they bring a significant performance benefit
on Windows.
* Memory limiting does now work in batch mode as well and is still
enabled by default.
* The old UndoTokenWithSize CRTP hack could be removed.
UndoStack operations should be a bit faster now.
But on the other hand, there will be an overhead due to repeated
memory limit checking on every processed character.
|
|
* the new "?" (help) command can be used to look up
help topics.
* help topics are index from $SCITECOPATH/women/*.woman.tec
files.
* looking up a help topic opens the corresponding "womanpage"
and jumps to the position of the topic (it acts like an anchor
into the document).
* styling is performed by *.woman.tec files.
* Setting up the Scintilla view and munging the *.tec file
is performed by the new "woman.tes" lexer.
On supporting UIs (Gtk), womanpages are shown in a variable-width
font.
* Woman pages are usually not hand-written, but generated from manpages.
A special Groff post-processor grosciteco has been introduced for this
purpose. It is much like grotty, but can output SciTECO macros for styling
the document (ie. the *.woman.tec files).
It is documented in its own man-page.
* grosciteco also introduces sciteco.tmac - special Troff macros
for controlling the formatting of the document in SciTECO.
It also defines .SCITECO_TOPIC which can be used to mark up
help topics/terms in Troff markup.
* Woman pages are generated/formatted by grosciteco at compile-time, so
they will work on platforms without Groff (ie. as on windows).
* Groff has been added as a hard compile-time requirement.
* The sciteco(1) and sciteco(7) man pages have been augmented with
help topic anchors.
|
|
* Allows us to check for the Gob2 version at ./configure time
* this file ships with Gob2 installations, so in most cases
it could be found without shipping it with SciTECO.
* Autoconf is built such that source distributions will contain
all additional external macros compiled in aclocal.m4.
* However if somebody builds from Git, he/she would still
expect the ./configure checks to produce meaningful results
even if not all dependencies are installed properly.
It therefore seems to be good practice to include all
external M4 macros (gob2.m4) as a fallback with the source tree.
* /usr/share/aclocal contains many more useful m4 macros.
However since we can depend on pkg-config e.g. for finding
Gtk+ and Glib, I won't use those macros as else I would
have to bundle them to achieve the same kind of ./configure
robustness.
|
|
* makes sense since it already extracted information from ./configure
that is usually substituted.
* it already had to be run from a configured build directory
* it required the source tree directory, which had to be overwritten
on the Make command line when using an out-of-source build dir.
This is no longer necessary.
* It is still a stand-alone Makefile to keep it isolated from the main
build system, although it could certainly be translated to Automake.
* the generated file will now be called distribute.mk to signify
that it is a Makefile.
|
|
* Autotest ships with Autoconf, so it's available already
and relatively easy to integrate into an Autotools package.
* This is attached to `make check` using some Automake magic.
* The test suite will only call the built SciTECO for the time being.
But using tests/Makefile.am, custom programs could be easily
built.
* Since it uses the target sciteco, it cannot work in cross-compile
environments.
* The test suite tests/testsuite.at should be used for regression
tests at least: Whenever there is a bug, a test case should be
added to testsuite.at.
Later this might be split up into multiple includes for regressions
other tests.
|
|
* Usually, Scintilla will now be built with -O2
* this can improve performance significantly over the standard Scintilla -Os
(up to 10%).
* this also allows link-time-optimizing both Scintilla and SciTECO
(which are linked statically) by adding -flto to CFLAGS, CXXFLAGS and LDFLAGS.
Link-time-optimization will both reduce the total binary size
and improve performance slightly since scintilla_send_message() can be
inlined.
An -O3 optimized Scintilla when linked with LTO results in an only 300kb
larger SciTECO binary.
* the highest possible optimization thus requires the following maintainer
flags on the ./configure command line:
CFLAGS="-O3 -mtune=native -march=native -flto"
CXXFLAGS="-O3 -mtune=native -march=native -flto"
LDFLAGS="-flto"
* Windows and Debian builds use link-time-optimization now.
On Windows - where we link in everything statically - building
the dependant libraries with -flto could improve performance
even more.
* Debian builds respect the default hardening flags of the build
server now. This should ensure that SciTECO is built for the
correct architecture at the recommended optimization level etc.
|
|
* use libtool convenience libraries as much as possible
(for all static libraries except Scintilla)
* improves separation of language and user interface implementations
(e.g. the Gtk widgets are not interesting for the rest of SciTECO)
* the Curses popup widget can now be factored out of interface-curses.cpp
* some common CPPFLAGS are now defined by ./configure via AM_CPPFLAGS,
so they don't have to be repeated in each submodule.
* fixed building the Curses UI: GTK_FLOW_BOX_FALLBACK conditional
must always be defined.
|
|
* depend on Gtk+ 3.10. If necessary older versions should also
be supportable. GtkOverlay was already introduced in v3.2
* A fallback for GtkFlowBox is compiled in if the Gtk installation
is too old. This applies even to Ubuntu 14.04 which still runs
Gtk v3.10.
* the threading the Gtk UI is left as it is for the time being
even though the synchronization mechanism has been deprecated.
Alternative approaches have to be tried out and benchmarked.
* Completely revamped the GtkInfoPopup widget.
It is now as powerful as the Curses UI's popup widget.
* A GtkOverlay is used instead of the top-level window hack
in the Gtk2 version.
* GtkFlowBox is used to lay out the columns of the popup.
* I had to work around restrictions of GtkScrolledWindow
by writing my own poor-mans scrolled window which handles
size requests correctly.
* The popup window no longer overflows the screen size,
instead we scroll.
* Scrolling pagewise is finally supported. Wraps at the
end of a list just like the Curses UI.
* Instead of using only two stock icons, we now use
GIO to get file and directory icons for the current theme.
This looks even better.
* The GtkFlowBox allows selections which can be used for mouse
interaction later. But this is not yet implemented.
* Theming of the popup widget and command line is still
not performed correctly.
|
|
* Haiku can be handled like UNIX in most respects
since it is POSIX compliant, has a UNIX-like terminal
emulator and uses ncurses.
* still the Glib platform macro is G_OS_HAIKU instead of
G_OS_UNIX, so the preprocessor conditionals had to be adapted.
* the only functional difference between a Haiku and UNIX build
is the default SCITECOCONFIG path.
We use the config path returned by Glib instead of $HOME,
so .teco_ini will be in ~/config/settings on Haiku.
Other UNIX ports appear to use the same conventions.
* Some Haiku-specific restrictions still apply:
* Haiku's terminal is xterm-compatible, but only supports
8 colors. Therefore only the terminal.tes color scheme
can be used and the terminal must be set up to
"Use bright instead of bold text".
* The terminal has artifacts. This appears to be a Haiku
bug and affects other curses applications as well.
* GTK is yet unsupported on Haiku, so there may never be
a GUI port (unless someone writes a QT GUI for SciTECO).
* SciTECO cannot be built with the legacy gcc2 used for
BeOS compatibility on Haiku. This would require too many
changes for an obsolete platform.
BeOS and the x86_gcc2 platform of Haiku will therefore
never be supported.
The PPC and ARM platforms of Haiku should work but are untested.
* a HaikuPorts recipe will be provided for the next regular
SciTECO release. This should hopefully allow installation via
HaikuDepot.
|
|
* enabled via --with-interface=xcurses, so we can configure
it automatically via xcurses-config.
This also adds XCURSES_CFLAGS and XCURSES_LIBS.
* The X11 window class name is set to "SciTECO".
X11 resource overrides can currently not be set via
sciteco's command line. The user may use .Xdefaults though.
* interruptions via CTRL+C are currently not supported.
Apparently, XCurses also does send SIGINT in cbreak() mode.
An XCurses-specific hack would be cumbersome.
* ~InterfaceCurses() should probably be rewritten.
Curses cleanup should be completely in restore_batch() as
the destructor may be called after Curses-cleanup handlers.
E.g. isendwin() SEGFAULTs on XCurses when called from the
destructor.
|
|
* requires a recent patch to Scinterm
* can be overwritten in SciTECO's build system via NCURSES_CFLAGS or
PDCURSES_CFLAGS.
* NCURSES_LIBS has also been introduced. The check for ncurses
will now use pkg-config if available.
* eases multiple builds with different Curses variants
(e.g. when cross-compiling for Windows)
* pass more toolchain variables into Scintilla build process (CC and RANLIB).
This should fix Cross-compiling Scintilla/Gtk
* Pass GTK cflags into Scintilla/Gtk build system.
|
|
minimum version
* it was necessary to increase the upstream version so I could
upload new versions to launchpad while debugging PPA build issues.
* ChangeLog finalized for v0.6.4
* SciTECO requires at least libglib v2.28 (but that's only a guess)
|
|
* allows us to link against PDCurses/win32a statically.
It requires additional Windows DLLs (gdi32 and comdlg32) and since
there's no PDCurses configuration mechanism, it is easiest to set
the PDCurses linker flags using a PDCURSES_LIBS env variable.
* This is only possible since Scintilla links statically, we do the
linking of the binary and can provide the linker flags.
It is still not possible to overwrite the CFLAGS used for PDCurses
without modifying the Scinterm Makefile.
* Using PDCURSES_LIBS we can get rid of --with-interface=emcurses since
if library checks fail with EMscripten, we can simply define
PDCURSES_LIBS="-lpdcurses"
|
|
the MSVCRT versions are not glibc-compatible and we do not
actually need glibc compatible versions, as all allocations
are done through the libglib wrappers.
|
|
* activated via bit 4 of the ED flag (enabled by default)
* automatic EOL guessing on file loading and translation to LFs.
* works with files that have inconsistent EOL sequences.
* automatic translation to original EOL sequences on file saving
* works with inconsistent EOL sequences in the buffer.
This should usually not happen if the file was read in with
automatic EOL translation enabled.
* also works with the EC and EG commands
* performance is OK, depending on the file being translated.
When reading files with UNIX EOLs, the overhead is minimal
typically-sized files. For DOS EOLs the overhead is larger
but still acceptable.
* Return (line feed) is now an immediate editing command.
This centralizes EOL sequence insertion.
Later, other features like auto-indent could be added to
the editing command.
* get_eol() has been moved to main.cpp (now called
get_eol_seq()
* Warn if file ownership could not be preserved when
saving files.
* IOView has been almost completely rewritten based
on GIOChannels. The EOL translation code is also in IOView.
|
|
|
|
* sciteco.ico contains a 16 color 16px, a 255 color 32px and
a true color 48px version of the icon.
The first ones are good for legacy Windows versions like 2000,
while the latter one should be preferred by Windows >= 7.
* Also added the 48px version as a PNG for Linux.
But it is not installed currently, as there is no standardized
place for it and it wouldn't do much good in /usr/share/sciteco.
|
|
* This adds the -all-static libtool option and can be used to
link a static sciteco binary (or at least link in as few as possible
dynamic libraries)
* Esp. useful on MinGW to link in all dependant libraries (glib, libintl,
libiconv, libpdcurses, ...) statically.
A static .exe is much smaller than a dynamically linked plus all the
DLLs and is easier to relocate.
* This does not guarantee that ALL libraries are linked in dynamically.
E.g. on MinGW, the sciteco.exe will still link to MSVCRT and the Windows
system DLLs, but they already ship with Windows.
* On MinGW, even a static build will still require the gspawn-win32-helper-console.exe
which is used by glib to implement g_spawn with redirection.
We cannot get around that.
* It would be better to let this be decided by the package builder using
the standard env variables like LDFLAGS. However, this does not seem to
work well with libtool. It IS possible to define LDFLAGS="-all-static" when
calling make but this approach sucks.
|
|
* PDCurses build system produces static libraries that cannot be
found by Autoconf (pdcurses.a) and often files have the wrong
permissions.
|
|
* The PACKAGE_URL_DEV is also mentioned in --help output and sciteco(1)
|
|
* has been changed in Scinterm some time ago
* I don't know if defining this makes actually any difference,
but Jinx does it.
|
|
* this is a Linux/glibc-only optimization
|
|
$SCITECOPATH on Windows
* $SCITECOCONFIG has been introduced, so have a macro-accessible location
for the profile, buffer session etc.
This is set to the program dir on Windows. That way, the config files
will be found, regardless of the current working dir, but it may also
be set up for Unix-like environments on Windows.
* $SCITECOPATH defaults to the program dir + "/lib" now on Windows.
* The default profile is now always called ".teco_ini". Also on Windows.
Platform differences like this would need to be documented.
* The sample teco.ini has been renamed to "sample.teco_ini" for clarity
|
|
* does not change ./configure parameters
You still have to specifiy --with-interface=ncurses for
the Curses interface with default settings
* the "NCurses" UI was used for many different Curses
variants, so plain "Curses" is a better name.
|
|
The SciTECO language changes often and the build system scripts are
adapted accordingly. If bootstrapping is disabled by default on systems
that already have SciTECO, building recent Git versions will fail often
due to macro errors. This is not easy to see and correct for users.
Also the build-time overhead for `sciteco-minimal` is minimal. The
--disable-bootstrap option is mostly useful when cross-compiling
SciTECO.
|
|
this should simplify building SciTECO for new users
* compiler and archiver are passed down from Autoconf,
so cross-compiling should work transparently
* `make clean` will also clean the Scintilla source tree
* there is no longer any need for "source bundles" as
tar balls also contain Scintilla/Scinterm now
* building from Git is not much more difficult than building
from a tar ball
* The versions of Scintilla/Scinterm embedded as submodules
already contain all the patches necessary (currently none are
necessary), so there's no need to have patch files in the
repository
* INSTALL instructions have been rewritten
* the --with-scintilla and --with-scinterm site-config options
have been kept. But they should be rarely necessary now.
|
|
|
|
|
|
|
|
by building with Emscripten support, SciTECO may be
embedded into web pages.
* sciteco.html is not a piece of documentation but a sample SciTECO embedding
|
|
* there was a compile-time race condition that could result in the GObjects not being built (with Gob2).
So I removed the symbols generation from BUILT_SOURCES.
* apparently either Scintilla depends on gmodule since I last tested or the gtk+-2.0 pkg-config package
no longer includes gmodule, so we must explicitly depend on it
|
|
|
|
* some build environments (like XCode) do not have a GNU readlink by default
|
|
so no additional --with-scintilla is necessary when building from
a source bundle
|
|
* fixes gcc-4.4 which does not have -Wno-mismatched-tags and no -Wunknown-warning
|
|
|
|
|
|
* will be useful for Windows builds since Windows users usally do not have
a man-page formatter/reader
|
|
* solely for generating developer docs
* disabled by default even if Doxygen is installed
* Doxygen comments are not used currently
|
|
* storage size should always be 64 (gint64) to aid macro portability
* however, for performance reasons users compiling from source might
explicitly compile with 32 bit integers
|
|
useful for Windows where the desired default path does not correspond with
the installation dir of the std lib macros
|
|
may be used to have multiple scinterm-versions in the Scintilla source tree
|
|
...which is useful when crosscompiling for MinGW
|
|
* pkg-config LIBS should be added to $LIBS so that link order is correct
|
|
* SCITECOPATH environment variable defaults to this directory
* manpage updated
* default teco.ini updated: no need to generate it anymore
|
|
a common ./configure parameter would be --with-scintilla=~/scintilla.
however the calling shell will not expand tilde and the invoked
shell will not automatically fully expand variables.
|
|
was broken due to untested changes
|
|
later there will be much more documentation
|
