On 10/23/19 4:18 PM, Chase wrote:
> Most of it should work in theory™, but the most testing I did was to make 
> sure that we could get past the configure.ac file, but I made some changes 
> afterwards. I know what shouldn't work for sure is appbuilder, dthelp and 
> dtinfo, they use some imake magic that is pretty complex, makedepend also 
> doesnt work, not because i couldnt, but because I was thinking we would do it 
> at the compiler level when it came time for a merge and it wouldn't be 
> necessary. I seemed to have never written a Makefile for 
> programs/utils/dttypes (I did this a while ago, Ive been spending recent 
> efforts on trying to import a new version of ksh).
> 

Ok, I got past configure, but 'make' dies as there are no makefiles
generated (missing  AC_CONFIG_FILES() :)  I'm working on that now, just
for kicks.  I'll start with just lib/ at first.

I'll probably just disable dthelp, doc, dtappbuilder, etc until the rest
of it can build and work fine.  Then we can tackle the trouble makers.

Good move on ksh - another 'sore spot' in need to reworking.  Ideally we
could just link against an official version of the new ksh rather than
build one ourselves.  Guess we'll see.


-jon

> 
> Thank you for your time,
> -Chase
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, October 23, 2019 5:02 PM, Jon Trulson <j...@radscan.com> wrote:
> 
>> On 10/23/19 3:58 PM, Chase wrote:
>>
>>> I mimicked imake in this case, and put an include to a file that uses 
>>> variables for a cpp command. There might be a better way to do this (this 
>>> might not even work at all), but I was hoping to stick to what works for 
>>> now and autotoolize the code as we go along, the configure.ac also mimicks 
>>> imake in the sense that it uses os detection rather than feature detection.
>>
>> Yeah. I was thinking to use tradcpp - single source file, bsd licensed,
>> that can act just like cpp and we can include it as part of the build.
>> But that can wait for now.
>>
>> I've tried to build it and there are some missing pieces still in
>> configure.ac, Makefile.am. I'm hacking on it now :)
>>
>> But - is any of this expected to work yet, or were you just filling in
>> pieces first?
>>
>> It would help to know what is expected to work and what isn't at this
>> stage. Again, thanks for the effort!
>>
>> -jon
>>
>>> Thank you for your time,
>>> -Chase
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On Wednesday, October 23, 2019 4:45 PM, Jon Trulson j...@radscan.com wrote:
>>>
>>>> On 10/23/19 2:56 PM, Chase via cdesktopenv-devel wrote:
>>>>
>>>>> I tried to make these patches as distinct as possible, this constitutes
>>>>> an estimated 80% of the code covered
>>>>
>>>> Nice! I can see that took a long time.
>>>> As discussed, I have applied these patches to the new
>>>> autotools-conversion branch.
>>>> Nice work Chase - this gives us a good start on an autotools building
>>>> future :)
>>>> I look forward to trying it out soon.
>>>> How did you handle the cases where cpp is used to pre-process various
>>>> files (doc, .ksh scripts, UDB, etc)? I haven't looked yet.
>>>> [...]
>>>>
>>>> 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
> 

-- 
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

Reply via email to