LADSoft
CMAKE testing
these are the ones I'm going to be looking at.
asl covscript duilib gravity katascript nana simplecpp
there are several problems; the ones most problematic are nana which requires c++17 and covscript. DUILIB has linker pragmas in the cmakelists.txt so I don't know how far I'll get with it...
Depending on how much time I have I elect not to touch nana until after the next release as it requires updates to CMAKE and I don't remember how to set up a test environment for that.
the other major issue is a lot of the files in COVSCRIPT are just hanging the compiler....
I already fixed a couple of minor crashes though.
So while I was working on the autoconfig projects I found the libmpir is now harnessed with cmake rather than automake... so I compiled it against OrangeC and things went well. Completed the compile properly the first time.
ive been working on this issue over the last week or so. Asl.dll compiled pretty quickly base on earlier work I had done with it although I haven't spent a lot of time compiling its test suite yet. Covscript has been giving me headaches though. It started out by locking up the compiler then devolved into crashes and lots of errors. I'm making progress though. The main file is not crashing the compiler any more and has a manageable number of errors... This one is intense enough that I'm going to move it into the compiler test suite when I get it working....
i havent had an update in a while... i took a break during july but before I did that I got mostly through compiling COVSCRIPT.CPP. There were a lot of problems compiling this particular project so it is a very good exercise to be working on ths... as I left it the 32 bit compiled compiler couldn't compile it, too complex and occ ran out of memory... so i switched to testing with the 64 bit compiled compiler. There was one error that was flagged 15 seconds into compiling covscript.cpp with the release version of the 64-bit compiled compiler, but occ couldn't compile itself any more. Then I went on break....
I came back in late august and got occ to compile itself again but then I introduced more errors compiling covscript.cpp... so im going back and forth trying to get it to compile itself and at the same time compile covscript.cpp. Once I get that worked out I'll take out any remaining bugs compiling the covscript project then move on to duilib...
@chuggafan I've come a long way on the COVSCRIPT compiling issues. Seems like there were dozens of them generated but this one program suite alone.
I'm almost at the end of it but I'm having a little problem.
the following code snippet won't compile with OCC though it compiles with other compilers:
#include <functional>
struct aa
{
int nn(int);
};
std::function<int(aa&, int)> bb(&aa::nn);
I looked into it and it seems this is a failure with LIBCXX, it does not seem to support initializing std::function with a member function this way... there is a whole other set of classes devoted to dealing with member functions and absolutely no support I can see in the main functional class for dealing with it.
The AI says this is a valid construct since C++11....
I was wondering if you could look in
I don't think this is a failure with libcxx, if I use x86-64 clang 10.0.0 (which uses libcxx of the same version) on godbolt I get a successful compile https://godbolt.org/z/nc8W4E36P What output are you getting?
here is what I get for the output:
occ (OrangeC) Version 6.73.1
Copyright (C) LADSoft 2006-2025
Error(232) s3.cpp(8): Could not find a match for 'std::function<(*)(aa&, int)>::function(((aa::*)(int)))'
1 Errors
i did a little digging and it appears that LIBCXX handles 'is_function' a little differently for clang, there is a builtin which is called for clang vs a hack for everything else... that affects std::decay.... maybe after i eat i will play with that a little....
I also looked at the sources for VS std::function and other than a lot of fluff it doesn't seem much different from LIBCXX with regards to member pointers.... so yeah I guess it should work and I'm missing some basic understanding....
I'm not sure this has to do with is_function because if I do a quick checkthrough of "is_function or __is_function" throughout the file <functional> it turns up absolutely nothing, and the number of instances where it does in other files (which are a handful outside of tests) are few and are definitively NOT related to std::function. And that would nominally make sense, however for this the alternative is_function check passes: https://godbolt.org/z/jW7vY4ezh
That output does indicate to me that it can't deduce that the std::function template fits, the question is why. the derivative from maybe_unary_function (not exact name) does no checks, the derivative from maybe_binary_function (also not exact name) does no checks.
Something we should add is something similar to what gcc/clang/msvc did where the decision tree of "Ok, we tried X candidate but it failed because Y" would be really good for debugging this type of thing.
i figured this out late last night.... issue was that a decltype for member pointers had to have deferred evaluation because it appeared in a template declaration... but there was no provision for deferring .* or ->* operators until things are instantiated. once i fixed that it compiled ok. Occ isn't generating good code right now though so I couldn't vet the results...
it took me all summer, but I got covscript to compile. The main problem is that some of the files are complicated enough that compiles take a long time. I've got some ideas about improving that but we will see....
Haven't tried to link it, haven't tried to go beyond covscript to the other projects. Moving to milestone 4a