Additionally, ninja or meson would ‎severely restrict platform support. CMake could be alright.

It would be great to see DtMail given new life.

-mrt
From: Christopher Turkel
Sent: Wednesday, February 20, 2019 20:50
To: CDE development
Subject: Re: [cdesktopenv-devel] Back in the flock

Bring back CDEbian, that would be great!

CDE still builds on OpenBSD just fine, since that's what I use these days.

On Wed, Feb 20, 2019 at 9:47 PM Jon Trulson <j...@radscan.com> wrote:
On 2/20/19 1:53 PM, Danilo Pecher wrote:
> Hi everybody, 
>
> I've been away for quite a while from CDE related work, so long in fact,
> I don't even have the same name anymore. Back then I was going by the
> name of Danilo Schöneberg, now I'm Danilo Pecher. The reason for that is
> simple: I got married at the tender young age of 44. 
>

Congratulations! :)

> Now that I'm getting back to contributing, I've got a few things in mind
> to work on in the near future, and would like some input from others: 
>
> 1. One of the first things I'll be doing is streamlining the build
> instruction pages. They've become cluttered a bit and I want to test if
> some of them are still working. Especially NetBSD is a bit of a tricky
> patient here. On 7.2 everything works and on 8.0 half the stuff is
> broken. Some work to do there. For most systems I'll probably provide
> automated build-scripts. 
>

Quite possible - I've only been testing with FreeBSD 11 in addition to
the Ubuntus.

> 2. Although I've been rather inactive on the project itself, I've not
> been completely idle. I'm about 75% done in creating a CDE-based Linux
> distro based on LFS, complete with automated build. What do people
> think? Would there be a "market" for that? 
>

Linux From Scratch?  Probably... I've heard several people wanting the
CDEbian distro to be resurrected/maintained, so I assume there are those
what would love a one-stop solution.

> 3. Point 2 sort of exposes that we've got a massive problem in terms of
> applications. Except for editors (both VIM and Emacs come with Motif
> GUIs and integrate nicely) we've got close to no apps that really
> integrate seamlessly. Well, we can probably agree that there'll never be
> a dtwww web browser, unless someone wants to take leave of his/her
> social life to write a motif based web engine, but I think we should be
> able to modernize dtmail and ship in a slightly more versatile default
> text editor (you may take that as me volunteering) 
>

Yay :)  I think dtmail needs to be fixed, or removed.  It doesn't
support a lot of things a modern mailer would, like for example SSL/TLS :)

Making dtpad a more modern and useful editor would also be cool.

> 4. I know work is going on for an autotools conversion. In that regard,
> I'd like to ask if we aren't going to end up being Betamax-man again. At
> least by the look of it, cmake/ninja/meson seem to be taking over in a
> growing number of projects. While we're at that, I'm going to set the
> cat among the pidgeons a bit. Would it not be a better idea to make a
> hard break with the current (chaotic and nigh-on impossible to
> comprehend) build system and switch to a clean-sheet rebuild for a 3.x
> release?

I think autotools will be around for awhile (Hows that going Chase?).
But I have been thinking CMake might be nice too.  That one seems to be
getting more and more popular, and it can generate ninja files too.  It
also has the benefit of maturity and wide spread adoption.

I might spend some time looking into that when I get some time.

I think meson is too young at present -- though I've never tried it.  I
have done CMake though, and I do like it.  autotools m4 makes my brain
hurt :)

> Perhaps, if we do that, we might also get a chance of getting rid of
> the ksh-dependency for dtterm. That's been giving me rabies since
> 2016. ast-ksh seems to be all but unmaintained. and that's the only
> suitable candidate on a variety of platforms (BSD mainly, but also
> LFS, slackware and serveral other Linux variants on which it only
> builds on a sunny day with less than 3 knots of wind)>

Well, I wasn't aware that dtterm depended on ksh - that we should be
able to get rid of I would think.

I do know that building CDE's dtksh/ksh requires an already working ksh
install (sigh).

But att-ksh is actively being maintained here:

https://github.com/att/ast

I'm "following" them in git-speak.  They have removed a great deal of
cruft, fixed many bugs, and are only maintaining the parts of AST that
ksh actually depends on.  Check the commit history...

I'd love to dump our version and use that one someday.  It also has the
benefit of not requiring ksh to... build ksh. :)

> Okay, so much for now, I'll start firing up my test boxes to see which
> systems we correctly build on. Ubuntu 14.04, 16.04 and 18.04
> successfully checked out today. 
>

Welcome back!


--
Jon Trulson

  "The Party told you to reject the evidence of your eyes and ears.
   It was their final, most essential command."

   -- 1984


_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel

Reply via email to