| Age | Commit message (Collapse) | Author | Files | Lines |
|
$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
|
|
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.
|
|
* this allows us to remove the last patch to the Scintilla/Scinterm code
base (for the time being at least)
|
|
|
|
* allows us to remove most patches. One however is still necessary
(Scinterm Makefile bug!)
* TECO-style control code echoing is now set up using the SCI_SETREPRESENTATION message
* updated copyrights
* updated TODO
|
|
* useful when uploading into PPA for different series
|
|
|
|
|
|
|
|
|
|
* distributed binary packages are standard debian packages
* ./distribute might fix up the package version and branch for Ubuntu/PPA
|
|
so no additional --with-scintilla is necessary when building from
a source bundle
|
|
|
|
|
|
* MinGW binaries are built from source bundles
* patches are applied to the source bundle
* so all necessary patches must be in the repository and distributed
* use a leading number in patch names to ensure proper application order
|
|
* can build source bundles
* debian source and binary packages
* Zipped Windows binary
|