On 11/15/19 7:06 PM, Matthew R. Trower 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).
That may be true... Though some googling does indicate meson and ninja will work on Solaris. How well... no idea. My point was that I would rather use meson as a temp workaround to building ksh than be stuck with the old nmake stuff, which as Chase said: No one but the author knows how it works" :) In the short term, if we could just 'drop in the latest ksh', use meson to build it if that's required, then we do "our thing" in dtksh. I think if we are going to go to the trouble to finally update ksh, we should go all the way... That was the point of my last email. Long term there would be two choices: 1. autotool it, and deal with maintaining our own autotools build for it. This would be painful once, and probably not so bad afterward. 2. Even better long term - we could just make it an external dependency - ie install the 'ksh-dev' package which would include the library (libshell) and headers so that dtksh could just do it's thing without having to build it at all. That would require coordination with them I would think and I don't know what their plans are in that regard, though Marcin, who's contributed to CDE, is apparently pushing for that. So it's "not impossible" :) > > 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. > I would only consider it if someone actually did the work and submitted a usable, working implementation. :) Using meson in the form discussed previously would be temporary anyway, basically just a POC in the autotools-conversion branch. And the autotools-conversion branch isn't going to show up in master soon anyway :) If we can actually get something working, it would "probably" not take more than a day or three to get comparable autotools support working for it. -jon > > -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 > -- 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
