Ticket #120
Change libtool's shared library version info to 3:0:1 to preserve the
previous library version of 2.1.0.
See https://autotools.io/libtool/version.html for the details on how
libtool handles this versioning info.
See https://verbump.de/ for a handy 'version calculator' using
libtools rules.
Hardcoding a -lstdc++ is wrong, since not all OSs are likely to handle
C++ in the same way.
The issue is that libtt needs to be built as a C++ library, so we use
a fake dummy.cxx file to convince libtool to do so instead, rather
than trying to force the issue by linking a (possibly missing)
libstdc++.
Previously in the imake world, changing the CDE version required hand
editing a handful of files.
This commit makes these files into ".in" files. configure.ac now
holds CDE version information -- both in the AC_INIT() call and in the
CDE_VERSION_* variables a few lines down.
Changing the CDE version now involves editing those two locations in
configure.ac only.
Thereafter, a configure run will replace version information in the
following files with the current CDE version:
copyright
doc/common/help/HELPEnt.sgm
include/Dt/Dt.h
lib/tt/bin/ttauth/ttauth.man
This also causes a catch-22 problem with ToolTalk. So the
tooltalk.inc file is gone and the relevant TT Makefiles have been
modified to set and define the TT version in those Makefiles that
actually use it.
Such environments are missing void type, older K&R C, and
such supports already had been removed in various places.
Furthermore, current hardcoded 'SIGNALRETURNSINT' is wrong.
This commit will not completely remove all Imake files, specifically
those for sections that have not been completed yet.
Also, the databases dir has been moved to databases-delete-later until
we have everything building and installed properly.
CDE has relied upon catgets() implementations following a relaxed
interpretation of the XPG internationalization standard that ignored
-1, the standard error value returned by catopen, as the catalog
argument. However, this same behavior causes segmentation faults with
the musl C library.
This patch:
- Centralizes (with the exception of ToolTalk) all calls to catopen(),
catgets(), and catclose() through MsgCat within the DtSvc library.
- Prevents calls to catgets() and catclose() that rely upon
undefined behavior.
- Eliminates a number of bespoke catgets() wrappers, including multiple
redundant caching implementations designed to work around a design
peculiarity in HP/UX.
- Eases building CDE without XPG internationalization support by providing
the appropriate macros.
CDE has relied upon catgets() implementations following a relaxed
interpretation of the XPG internationalization standard that ignored
-1, the standard error value returned by catopen, as the catalog
argument. However, this same behavior causes segmentation faults with
the musl C library.
This patch:
- Centralizes (with the exception of ToolTalk) all calls to catopen(),
catgets(), and catclose() through MsgCat within the DtSvc library.
- Prevents calls to catgets() and catclose() that rely upon
undefined behavior.
- Eliminates a number of bespoke catgets() wrappers, including multiple
redundant caching implementations designed to work around a design
peculiarity in HP/UX.
- Eases building CDE without XPG internationalization support by providing
the appropriate macros.
With this patch, CDE (autotools) builds and runs on fbsd 12 now.
fbsd11 should work too, but not yet tested.
You must use gmake - ie:
./configure MAKE=gmake
gmake
Seems all of the BSD's will need to use gmake for now.
Certain programs like dtlogin and tt_type_comp need access to the
system's cpp command to process certain files at runtime. tradcpp is
not installed on most systems, and is intended for use as a imake-cpp
replacement which is all we are using it for. We still need an
honest cpp for the CDE components to use.
Now, we look in various places for a 'cpp' command and set CPP_COMMAND
to it's value. This way tt_type_comp and other CDE programs can do
required processing at runtime.
There is a problem with CPP_PROGRAM - using $CPP or $GENCPP (tradcpp)
always fails in tt_type_comp with the error:
"nclude ", line 8: syntax error
If I define it to /lib/cpp (previous hardcoded value) then it seems to
work fine. Only the dtinfo and dtinfo_start ptypes use #include, and
therefore show this error. Needs investigation.
Also, restructure some of the dependencies in the lib/tt binaries. We
will link with libtt (which will include libtirpc as a dependency),
and XTOOLLIB - all the right X11 stuff without needing to add it to
every OS. Removed several uneeded OS specializations ("if LINUX",
etc) as a result.
This means that when linking against libtt, libtirpc should also
automatically be linked in if we determined that we are using tirpc.
This avoids having to link every program that uses libtt (almost all
of them) from having to have a $(TIRPCLIB) added to their link
commands.
cppfile.inc - don't set BUIT_SOURCES or CLEANFILES here as they
overwrite (or in case of the CLEANFILES +=...) ignore the settings.
Do those in the Makefile.am always.
We still need a better way to preprocess generic files. cppfile.inc
will only work for one file per Makefile...
Some files were trying to access the global includes directy in the
build area with things like #include <api/c/tt_c.h>, which is now
wrong. Se we fix all of those up. tt_c.h and tttk.h are now global,
so we no longer need to root around various build dirs to find them.
TT builds again.
Ok - so one of the steps in building CDE is an early phase called the
includes phase (make includes). At this point, all of the public
header files are exported to exports/include/Dt, DtI, ...
Then, the software is built using that include dir.
This of course does not work in autotools. Much of the software does
things like #include <Dt/something.h>, so in order for the build to
succeed, this behavior must be represented/replicated in some way.
It seems the usual way of dealing with this is to place all public
headers (and in some projects, ALL headers) into a toplevel include
directory.
We now do this for all public headers - they have been moved from
wherever they were and placed in the appropriate spot in includes/
This will break the Imake 'make includes' phase unless the Imakefiles
are fixed (remove the HEADERS = stuff, and the incdir defines). This
has not been done at this point since in reality, once autotools works
properly, there will be no need for the Imake stuff anymore, and I
intend to get rid of it.
This is just a warning for now - Imake builds in this tree will now
fail at the 'includes' stage.
This commit is only the migration. In upcoming commits, libtt will be
fixed so that the hack being used before to get around this problem is
removed as there will no longer be any need.
And then the autotools work continues...
