make distclean ignores the language definitions, as it should.
However, we had options that suggested that the Japanese locale was
supported. Distclean would decend into that locale directory and
fail, since of course we do not actually support that locale and it is
not currently buildable.
Remove a pile of old SGML stuff we no longer need in dtdocbook since
we use NSGMLS.
Use some TCL macros from m4/tcl.m4 to loacate and use information in
the tclConfig.sh script installed with TCL. I had to modify it to
export TCL_INCLUDE_SPEC, which was present but not imported.
So this is going to be tricky/painful getting this parser fully
operational. It's pretty hairy with various interdependencies and
generated code.
It's rather complicated how each sub dir depends on the previous one.
Also, the parser subdir has dependencies on the helptag subdir, and
vice-versa, so some hackery was needed to get that to work.
Due to the wierd interdepencencies between helptag and parser,
we disable parallel builds there.
This is some really horrible code and design - not surprising since it
dates to 1989.
I think it should just be removed -- who can maintain or refactor this
code?
Also, dthelp_htag1 is now built in pass1/parser/, not in
pass1/helptag/ as it used to be.
The appmanager action files (/usr/dt/appconfig/appmanager/*) are now
created properly for the main 4 languages supported. As usual, the
en_US.UTF-8 locale is a symlink to C.
These files were previously created via the UDB database files via
imake. Obviously we aren't going to be using those in autotools.
So, each language now has an appmanager/ dir in
programs/localized/$LANG/ that will create them properly on a make and
make install. It uses a new appmgr.am template in localized/templates
to do this.
This also means all of these languages now can use the new actions
added by Antonis, even though they are not translated, they are at
least usable in those languages now.
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.
1. On OpenBSD, and check is made for only bison or byacc. yacc is
present, but not usable apparently. So - need to install bison on the
BSD's.
2. the libjpeg.h check fails as it is located in a non-standard
location (/usr/local) on BSD systems. Just remove the check for now
until we have a better way to check that stuff (like X11 and Xm
headers too).
A list of major things like ksh, cpp, etc are saved in a list if they
are not found. If this list is non-empty when configure is nearly
done, an error message is displayed listing the missing programs.
This is less annoying than stopping after every missing programs.
Also, removed the X11/Xm header checks for now. Those need to take
into account X_CFLAGS in some way since these files are located in
dirfferent areas on different OS's (obsd puts them in
/usr/X11R6/include for example).
... and move the PROG_CC and PROG_CXX checks toward the beginning.
Without the move the compiler search arguments are ignored. We search
for 'cc gcc clang' and 'c++ g++ clang++', in that order for CC and CXX
respectively.
This means there should be no need to override the CC
and CXX variables on the configure command line for BSD systems.
On OpenBSD for example, cc links to clang. On Linux, cc links to
gcc. You can still override these if you like with CC=... and
CXX=... on the configure command line.
gmake (MAKE=gmake) still needs to be used on the BSD's though.
With these and previous changes, CDE builds, installs, and runs
correctly on OpenBSD 6.5 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 are still some issues here - specifically with the C
dtbuilder/dtcodegen catalogs. They may be broken due to dtbuilder not
being built yet.
Also, once dtinfo can be built, the msgs and app-defaults for it
should be re-enabled.
I also see gencat coredumping in localization/ while doing a multicore
(-jX) make. Regular single core builds seem to work fine.
Make -lXinerama a dep on libDtXinerama so it doen't need to be
specified in Makefile.am files or in LIBS as it was being done
previously.
This still needs a little work, ideally Xinerama should be completely
optional and only enabled if present. But we can save that for
later.
