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
