| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
I've just set up a script that does code signing by a more sensible
method for cross-compiled Windows builds (i.e. still using the same
underlying technology, but not bothering to fire up a whole Windows
delegation environment that won't get used). So now I can use it.
|
| |
|
|
|
|
|
| |
I don't know how I managed to add a non-TLS URL in this new
code-signing command at around the same time that I'd just switched
over all the ones in my other projects. Must have copied and pasted
from an un-updated checkout, I suppose!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit updates the libcharset submodule to incorporate the
autotools-ification that I just pushed to that subproject, and builds
on it by replacing Halibut's own makefile system similarly with an
autotools setup.
The new Makefile.am incorporates both of the old Makefile and
doc/Makefile, so a single run of 'make' should now build Halibut
itself and all the formats of its own documentation, which also means
that the automake-generated 'make install' target can do the right
thing in terms of putting an appropriate subset of those documentation
formats in the assorted installation directories.
The old Makefiles are gone, as is release.sh (which is now obsolete
because autotools's 'make dist' doesn't do anything obviously wrong).
The bob build script is comprehensively rewritten, but should still
work - even the clang-based Windows build can use the
autotools-generated makefile system, provided I do the libcharset
build with a manual override of bin_PROGRAMS to prevent it trying to
build the libcharset supporting utilities (which are not completely
Windows-portable).
|
| |
|
|
|
|
| |
Or rather, clang in MS-targeted code generation but still with the
Unix-style command line, which lets me use the existing Makefile with
almost no change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I became aware a few months ago that enough is known about CHM files
that free software _can_ write them without benefit of the MS HTML
Help compiler - in particular there's a thing called 'chmcmd' in the
Free Pascal Compiler software distribution which is more or less a
drop-in replacement for hhc.exe itself.
But although depending on chmcmd would be a bit nicer than depending
on hhc.exe, Halibut has always preferred to do the whole job itself if
it can. So here's my own from-scratch code to generate CHM directly
from Halibut source.
The new output mode is presented as a completely separate top-level
thing independent of HTML mode. Of course, in reality, the two back
ends share all of the HTML-generation code, differing only in a few
configuration defaults and the minor detail of what will be _done_
with each chunk of HTML as it's generated (this is what the recent
refactoring in b3db1cce3 was in aid of). But even so, the output modes
are properly independent from a user-visible-behaviour perspective:
they use parallel sets of config directives rather than sharing the
same ones (you can set \cfg{html-foo} and \cfg{chm-foo} independently,
for a great many values of 'foo'), and you can run either or neither
or both as you choose in a given run of Halibut.
The old HTML Help support, in the form of some config directives for
HTML mode to output the auxiliary files needed by hhc.exe, is still
around and should still work the same as it always did. I have no real
intention of removing it, partly for the reasons stated in the manual
(someone might find it useful to have Halibut generate the .HHP file
once and then make manual adjustments to it, so that they can change
styling options that the direct CHM output doesn't permit), and mostly
because it wouldn't save a great deal of code or complexity in any
case - the big two of the three auxiliary files (the HHC and HHK) have
to be generated _anyway_ to go inside the .CHM, so all the code would
have to stay around regardless.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A long time ago, it seemed like a good idea to arrange that binaries
of Halibut would automatically cease to identify themselves as a
particular upstream version number if any changes were made to the
source code, so that if someone made a local tweak and distributed the
result then I wouldn't get blamed for the results. Since then I've
decided the whole idea is more trouble than it's worth, so I'm
retiring it completely.
[originally from svn r10254]
|
| |
|
|
|
|
|
|
|
|
| |
The \versionids in the docs are now added by the bob script; the one
in inputs/test.but has been replaced by fixed text (it didn't matter
what it contained anyway, of course, for test purposes), and the one
in misc/halibut.vim has simply been removed (it wasn't actually
expanded by svn anyway - it still had its old CVS value).
[originally from svn r10253]
|
| |
|
|
|
|
|
|
|
|
| |
The existing Halibut bob script defaults to building a completely
unversioned source tarball. I think building one with the version
format I'm now more or less standardising on (date + VCS id info) is a
more sensible default. So I'm retiring the SNAPSHOT setting, which I
never used anyway, and making the default work like that.
[originally from svn r10252]
|
| |
|
|
| |
[originally from svn r7225]
|
|
|
[originally from svn r7204]
|
