On 3/28/21 4:48 PM, Chase wrote:
Well if you had it working before that is a bit concerning, but I am
not sure if it is a regression or something wrong with my environment.
I would like a jenkins setup if possible. As for only doing work on
linux, since I am pretty much the only one doing work on the autotools
branch right now, I just kind of do whatever I feel needs work, so I'd
rather not limit myself. My main objectives right now are increased
portability, getting dtinfo to work, and fixing our issues with
variable substitution (setting CC to clang or tcc on linux causes the
build to fail). I would like to write out the builtin libc tools baked
into dthelp (this rswinton guy really likes reinventing the wheel) and
writing out some ifdefs to be feature checks instead, but I understand
that getting CDE to actually build is the priority right now.
Yes, it did work...
Basically I had to do:
./autogen.sh
./configure MAKE=gmake
gmake
and that was it.
But it has been a few months at least since I last tried it. I'll maybe
try it later this week.
WRT to CC/clang - I just tried this on ubuntu 20.04:
./autogen.sh
./configure CC=clang CXX=clang++
make
And it builds fine... fbsd uses clang by default and I know that works
with master (and did work on autotools in the past).
-jon
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 28, 2021 4:01 PM, Jon Trulson <j...@radscan.com> wrote:
On 3/28/21 2:39 PM, Chase wrote:
Just attempted it and I can't build anything with or without the
patch, aclocal says it needs gnu m4, but I already have gnu m4
installed...
Thank you for your time,
-Chase
Well, crap. I had been testing it occasionally (needed gmake though)
with success, but not recently. Guess maybe I should add the fbsd12
vm agent to the jenkins build for autotools-conversion.
I use it for master build testing, but not autotools as that's still
a work in progress. Maybe time to change that...?
Or maybe we don't care for now and address the BSD issues once linux
works? What's your thought on that?
-jon
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 28, 2021 1:55 PM, Jon Trulson <j...@radscan.com>
<mailto:j...@radscan.com> wrote:
On 3/28/21 9:52 AM, Chase wrote:
So it sounds like the makefile incompatibilities have been solved, and now it's
an issue of the code itself having problems with compatibility, so if you would
like to fix and maintain unixware support, be my guest. The makefiles appear to
have incompatibilites commented out and replaced with portable statements, so
maybe the *BSDs will be able to use their native make now? In any case, I'd
like to have this merged.
Have you tried this on a BSD system like FreeBSD?
As for a lightweight system v, I think solaris would be your best bet, but why
not go for a modern opensolaris fork that is actually maintained like DilOS or
Tribblix (theres even a video of this one running CDE on youtube)?
Agree on that...
-jon
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 28, 2021 1:27 AM, Lev<int...@mailbox.org>
<mailto:int...@mailbox.org> wrote:
Hi Chase,
Apologies, I haven't been able to spend as much time working on CDE and the
Korn shell as I would like recently.
I wanted to let you know that I couldn't use the autoconf v. 2.63 bundled
with Oracle Linux 6 (i386):
configure.ac:3: error: possibly undefined macro: AC_CONFIG_MACRO_DIRS
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
Like last time, I had to hack the configure script to work around missing
dependencies, but I encountered this Xinerama-related build failure
right away:
/bin/bash ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H
-I. -I../../include -DANSICPP -DMULTIBYTE -DNLS16 -DOSMAJORVERSION=4
-DOSMINORVERSION=15 -g -c -o DtXinerama.lo DtXinerama.c libtool:
compile: cc -DHAVE_CONFIG_H -I. -I../../include -DANSICPP -DMULTIBYTE
-DNLS16 -DOSMAJORVERSION=4 -DOSMINORVERSION=15 -g -c DtXinerama.c -KPIC
-DPIC -o .libs/DtXinerama.o UX:acomp: ERROR:
"../../include/DtXinerama.h", line 38: cannot find include file:
<X11/extensions/Xinerama.h> UX:acomp: ERROR:
"../../include/DtXinerama.h", line 43: Syntax error before or at:
XineramaScreenInfo UX:acomp: ERROR: "../../include/DtXinerama.h", line
43: cannot recover from previous errors
However, I was able to compile a randomly selected library (DtMrm),
which seems like a major improvement. Thanks!
Although UnixWare has been convenient for me to test against on hardware
I own, my preference would be to have a lean, open source SVR4 system
someday that anyone can use. What do you think of Solaris? I've been
running version 8 lately and found it to be pretty similar to UnixWare,
but I do not know what the legal situation is with the earlier source
code releases.
Also, I found out that libXfont is not taking advantage of FreeType's
support for using the now unpatented bytecode interpreter. I think it is
a rather substantial improvement and could help with internationalizing
CDE, because some of the free Microsoft web fonts, like Tahoma, support
many Unicode scripts within a single font. Also, the CJK bitmaps, MS
Gothic, SimSun, PMingLiu, and Gulim, take heavy advantage of the
bytecode interpreter from my understanding. I've attached a patch and
some examples.
--8<---------------cut here---------------start------------->8---
--- src/Freetype/ftfuncs.c
+++ src/FreeType/ftfuncs.c
@@ -3136,7 +3136,7 @@
int face_number, ttcap_spacing;
struct TTCapInfo tmp_ttcap;
struct TTCapInfo *ins_ttcap;
- FT_Int32 load_flags = FT_LOAD_DEFAULT; /* orig: FT_LOAD_RENDER |
FT_LOAD_MONOCHROME */
- FT_Int32 load_flags = FT_LOAD_TARGET_MONO; /* orig: FT_LOAD_RENDER |
FT_LOAD_MONOCHROME */
char dynStrRealFileName = NULL; / foo.ttc */
char dynStrFTFileName = NULL; / :1:foo.ttc */
char *dynStrTTCapCodeRange = NULL;
--8<---------------cut here---------------end--------------->8---
Unlike bitmap fonts that have to be digitally recast for each pixel
size, using a bytecoded TrueType font would allow for arbitrary scaling
using the X11 core font subsystem. I imagine that it would look quite
nice on a HiDPI display.
Thanks,
Lev
P.S.: For anyone else interested in obscure Unix systems, I've gotten
the Jam build system to work with old K&R compilers, even ones like
ULTRIX/VAX's that do not support string literal concatenation, etc.
It also now features support for recursively scanning includes for IFFE
headers and generating the appropriate configuration.
It's on GitHub at lkujaw/jam.
Chase writes:
Here is also another patch that might hopefully make some progress on
generating makefiles with unportable statements, lev, would you care to tell me
if this commit changes anything when building on unixware with a pregenerated
configure script?
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 14, 2021 6:52 PM, Chase via
cdesktopenv-develcdesktopenv-de...@lists.sourceforge.net
<mailto:cdesktopenv-devel@lists.sourceforge.net> wrote:
ugh, CTRL+enter is never consistent between apps.
1. libmmdb.a is now built inside DtMmdb, since building sources outside of the
directory messes up dependency tracking
2. the pmaker and dfiles programs seem to generate files that have no
differences between platforms, so therefor lets just commit them.
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 14, 2021 6:49 PM, chasenicetry...@protonmail.ch
<mailto:nicetry...@protonmail.ch> wrote:
Some notes:
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, March 14, 2021 4:48 PM, Jon trulson...@radscan.com
<mailto:j...@radscan.com> wrote:
Go ahead and post a patch... Not sure when I can take a look, but the likely
issue is the order of the libraries on the link line.
-jon
On 3/11/21 4:06 PM, Chase via cdesktopenv-devel wrote:
By the way, I have made Makefile.am for the dtinfo program (not dtinfogen) that
compile, but I can't get the convenience libraries to work, they keep
outputting missing symbols as errors. I can provide a patch if anyone is
interested/willing to take a look.
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, March 9, 2021 6:15 PM, chasenicetry...@protonmail.ch
<mailto:nicetry...@protonmail.ch> wrote:
The wiki says the user should create /var/spool/calendar for proper calendar
functioning, lets do this for the user instead upon installation.
Thank you for your time,
-Chase
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
<mailto:cdesktopenv-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
<https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel>
--
Jon Trulson
"Entropy. It isn't what it used to be."
-- Sheldon
X-No-Archive: Yes - savehttp://groups.google.com/
--
Jon Trulson
"Entropy. It isn't what it used to be."
-- Sheldon
--
Jon Trulson
"Entropy. It isn't what it used to be."
-- Sheldon
--
Jon Trulson
"Entropy. It isn't what it used to be."
-- Sheldon
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
