I believe there was a misunderstanding here. I was not suggesting that Chase's
work be thrown away. I was pointing out that a Meson dependency would possibly
throw away the major advantage of Autotools, and that this may be considered
undesirable.
If it's just a temporary dependency, contained in a development branch, then I
suppose there's no harm.
Carry on.
-mrt
Original Message
From: nicetry...@protonmail.ch
Sent: November 16, 2019 7:40 PM
To: d...@blackshard.net
Reply-to: nicetry...@protonmail.ch
Cc: j...@radscan.com; cdesktopenv-devel@lists.sourceforge.net
Subject: Re: [cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] make ksh build,
update to ksh93v-beta
If someone wants to port to meson, they can go ahead, but it wont be me, and
once the autotools are set up, I doubt it will be anyone else. I checked
meson's github and they still seem to lack support for aix, hpux, oracle
solaris and minix (for which I want to port to once the blockers for the debian
package are taken care of).
Thank you for your time,
-Chase
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 15, 2019 8:06 PM, Matthew R. Trower <d...@blackshard.net>
wrote:
> On the subject of Meson...
>
> Back when we were determining which build system to transition to from imake,
> autotools was selected for its wide wide range of platform compatibility.
> Meson was considered at that time. The thing about Meson is that it depends
> on python3.5 and ninja. Ninja in particular is, to my understanding, a
> porting concern to non-mainstream platforms (mainstream here ==
> Linux/MacOS/Windows).
>
> It's been some time since that discussion, and things may have progressed for
> other Unix targets. It may not be impossible to go that route; some research
> and testing would be required on various platforms.
>
> But if Meson does prove out to be an acceptable dependency, and the project
> goes in that direction, then one may wonder about the wisdom of going forth
> with an Autotools conversion branch at all...
>
> Something to consider.
>
> -mrt
>
> Original Message
>
> From: cdesktopenv-devel@lists.sourceforge.net
> Sent: November 15, 2019 7:16 PM
> To: j...@radscan.com
> Reply-to: nicetry...@protonmail.ch
> Cc: cdesktopenv-devel@lists.sourceforge.net
> Subject: Re: [cdesktopenv-devel] [PATCH] [AUTOTOOLS-CONVERSION] make ksh
> build, update to ksh93v-beta
>
> Alright... I will see what I can do with the latest branch, but I still feel
> that it would be best to move from version to version a bit more slowly,
> after all, there are over 22 years of changes in ksh by now...
>
> Thank you for your time,
> -Chase
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Friday, November 15, 2019 6:32 PM, Jon Trulson j...@radscan.com wrote:
>
> > On 11/15/19 5:21 PM, Chase wrote:
> >
> > > I can see why those commented out makefiles could cause concern. I did
> > > this because in the build order from the imake file (not sure if this is
> > > actually important, in fact I am pretty sure it is not, as mentioned
> > > later), it was built after programs that we are still trying to make
> > > build. So what I did was I moved it to the very beggining of the programs
> > > list, and made sure to thoroughly test it to build, which it does... at
> > > the beginning of the programs directory. So an additional patch will be
> > > needed to move it to an appropriate location in the configure.ac file.
> >
> > Hmm.... Yes - it tries to build dtsession next - I'll work on that next
> > when I get some time. But, it is still be possible to simply (after
> > running .configure) to:
> > cd programs/dtksh
> > make
> > In fact I just tried this, and it failed (full log attached):
> > ....
> > - /bin/cp
> >
> > /home/jon/src/CDE/cde/programs/dtksh/ksh93/src/cmd/nmake/pkg-cobol-mfcobc.mk
> >
> > /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/lib/make/pkg-cobol-mfcobc.mk
> > - test '' '=' ppcc
> > - /usr/bin/cmp -s ppcc
> >
> > /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/lib/make/ppcc
> > - 2> /dev/null
> > - /bin/mv
> >
> > /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/lib/make/ppcc
> >
> > /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/lib/make/ppcc.old
> > - 2> /dev/null
> > - true
> > - /bin/cp ppcc
> >
> > /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/lib/make/ppcc
> > - nmake --base --compile
> >
> > '--file=/home/jon/src/CDE/cde/programs/dtksh/ksh93/src/cmd/nmake/Makerules.mk'
> > /usr/bin/ksh: line 4: nmake: not found
> > mamake [cmd/nmake]: *** exit code 127 making Makerules.mo
> > mamake: *** exit code 1 making cmd/nmake
> > package: make: errors making
> > /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64/bin/nmake
> > package: make done at Fri Nov 15 17:21:14 MST 2019 in
> > /home/jon/src/CDE/cde/programs/dtksh/ksh93/arch/linux.i386-64
> > Makefile:637: recipe for target 'ksh93' failed
> > make[1]: *** [ksh93] Error 1
> > ...
> > Also, I think I would have preferred you use the latest meson branch, as
> > we don't want nmake or any of that other crap around either.... And we
> > definitely do not want to be stuck with an old version of the 'new' ksh
> > as a result.
> >
> > > As for us depending on meson, we do not, the branch I chose was one of
> > > the last that functions with the old nmake build system, which only
> > > depends on standard c as far as I am aware.
> >
> > With meson, at least temporarily, we could simply have the dtksh
> > Makefile call meson to build ksh first :)
> > I would vastly prefer that than to continuing to rely on old
> > unmaintained software (nmake, pax, etc - as well as the 'old' ksh tree
> > you decided to import instead of the latest stuff)...
> > -jon
> >
> > > Thank you for your time,
> > > -Chase
> > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > > On Friday, November 15, 2019 6:05 PM, Jon Trulson j...@radscan.com wrote:
> > >
> > > > On 11/14/19 7:26 PM, Chase via cdesktopenv-devel wrote:
> > > >
> > > > > First off, massive apology for the commit size, I did not realize it
> > > > > was
> > > > > going to be that big, and there really wasn't a good way to break it
> > > > > down that I saw.
> > > >
> > > > 38MB, yeah... that's pretty much impossible to review properly.
> > > > I probably would have done something like:
> > > > commit #1 - remove old ksh
> > > > #2 - add new ksh
> > > > #3 - fix this
> > > > #4 - fix that
> > > > ...
> > > > I'm not going to add this immediately to the autotools branch until I
> > > > know it builds and actually works. Even then, it might sit in it's own
> > > > branch for a bit (autotools-conversion-dtksh, for example).
> > > >
> > > > > A few things to consider before merging:
> > > > > I am not a lawyer, but it seems that the old ksh version that was
> > > > > provided with CDE was donated to the open group by at&t, to be
> > > > > distributed as their copyright work under the lgpl, with this patch,
> > > > > the
> > > > > copyright will return to at&t, and thus the license control as well
> > > > > (epl
> > > > > vs lgpl). It shouldn't be that big of an issue though, we can always
> > > > > fork, and I will gladly sacrifice license sovereignty for ~22 years of
> > > > > improvements.
> > > >
> > > > I don't expect it to be much of an issue, though I am not a lawyer
> > > > either.
> > > >
> > > > > I tried to make this work with imake, but everything I tried ended up
> > > > > with an "error: recipe commences before first target", I did not seem
> > > > > to
> > > > > get this error with automake, so into the automake branch it goes.
> > > > > This patch only works with linux, it needs to be built on the BSDs and
> > > > > solarises, shouldnt be that hard though.
> > > >
> > > > Does it actually build and work? I noticed that in theconfigure.ac,
> > > > you disabled generation of the relevant Makefiles (though I think the
> > > > way you did that is not actually valid WRT use of '#').
> > > > Will it actually build and work?
> > > > The fact you disabled those Makefiles implies that it does not...
> > > >
> > > > > Somewhere in the dtksh source, I commented out three lines, they
> > > > > reference tty_alt, editb and main, these symbols were found in a part
> > > > > of
> > > > > the ksh source that didn't seem to get built into the libshell
> > > > > archive,
> > > > > but doing so would have alleviated this issue, so I asked the ksh devs
> > > > > how I could get these to be added to the archive, to which they
> > > > > responded that they have no idea how nmake (the old ksh build system)
> > > > > works, only David korn himself knows, and they have switched to meson
> > > > > in
> > > > > their builds.
> > > >
> > > > Yes, I am aware of their use of meson. So, would that have to be
> > > > installed as well in order for this ksh to build?
> > > > Also, it would be nice to know exactly what you changed and where... A
> > > > README.md is perfectly fine in programs/dtksh/ ....
> > > >
> > > > > So I believe the best course of action would be to fork
> > > > > from here and get automake files into the root to build it (this is
> > > > > why
> > > > > I left the meson files in the source).
> > > >
> > > > Yes - we would probably need to do this, or require meson be installed
> > > > too. Simply 'forking' would need to be done carefully to allow for
> > > > future updates with minimal pain.
> > > > The current ksh is undergoing a lot of development - no doubt we would
> > > > need/want to upgrade it from time to time.
> > > >
> > > > > Marcin Ciezlak also jumped into
> > > > > the dev conversation and said he was looking to make sort of a shared
> > > > > library out of ksh (?, I'd have to ask more about it, but I want
> > > > > results
> > > > > now, so I am making this commit).
> > > >
> > > > Well... It's usually better to do something right than quick... I know
> > > > Marcin has talked about that for awhile now, and it would be ideal for
> > > > dtksh to simply use an external libksh/libshell library. But yeah, I've
> > > > heard that for years now :)
> > > >
> > > > > Sorry again about the commit size, i am going to look for a tool to
> > > > > tell
> > > > > me how big my commits will be before I commit them.
> > > >
> > > > Size is less of an issue - keeping commits confined to a single purpose
> > > > is more important - and use lot's of them...
> > > > Even if you had done this with 100 commits, at least they could be
> > > > individually reviewed, and problematic ones could be
> > > > redone/refactored/fixed.
> > > > With this single 38MB commit, it's either take it all or none of it.
> > > > I'll need some time to look it over and test... But - only if it will
> > > > actually build and work. If not, there is no point.
> > > > My first task though is to release CDE 2.3.1 this weekend - a month has
> > > > passed since the devel release.
> > > > -jon
> > > >
> > > > > Patch is here (my email provider wont send anything over 25M):
> > > > > https://gofile.io/?c=yRFsFn
> > > > > Thank you for your time,
> > > > > -Chase
> > > > > cdesktopenv-devel mailing list
> > > > > cdesktopenv-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
> > > >
> > > > --
> > > > Jon Trulson
> > > > "Nothing unreal exists."
> > > > -- Kiri-kin-tha
> > > > cdesktopenv-devel mailing list
> > > > cdesktopenv-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
> >
> > --
> > Jon Trulson
> > "Nothing unreal exists."
> > -- Kiri-kin-tha
>
> 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
