-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some build errors on Windows system(msys2) #19
Comments
Ah, yes. I was careless with the path conversions because this has been a slow effort to generalize the initialization logic from a bunch of commands I've been running manually on my own machine. In this case, just calling u8string() first is a quick fix, but the better solution is to leverage the new path API and have The quick fix is now in the |
You might have better luck with the Test target, assuming you have GoogleTest handy. The main method of the Debug target depends on ENIGMA's game engine source for input data, but the tests are totally hermetic. Only issue is that they're still rather small. I'm building them up with corner cases which JDI was originally written to gloss over—things that usually don't matter for code completion. The new C++ standards expose the entire language very explicitly, so I'm having to recode large chunks to look more like pages out of the standard. |
I'm on this branch, but the same error still exits. |
The problem is: Here, I see that in the document: std::filesystem::path - cppreference.com, and the document said:
So, on Windows, c_str() also return the native character type string, which is wchar_t type. But incfile.open() need a char* type string. |
I just missed a file. I fixed Main but not lex_cpp. Calling Patching |
I'm using such code:
You can create a branch, and then I can test it? CreateFileW is a native Windows API, and we could use the std's function if possible? |
Eh, Windows build's already broken. We'll get CI set up for it eventually. In the meantime, can't do worse than broken build. Pushed it as e44072c. |
There are some other build errors, such as:
|
It might be worth turning of -Werror in the build settings (or building with cmake). I hold myself to -Wpedantic-errors when building locally, but that's probably not the best way to get it running for you right now. Oh, also worth noting that |
OK. |
Please note that there is no function under Windows like:
If I comment out this function, than I get
So, I have to turning of -Werror in the build settings. I'm using cbp file. |
Oof, no catching SIGTRAP, either? That's fine; there is logic elsewhere that raises SIGTRAP using an inline assembly block, but only if the code being parsed contains Turning off Werror is probably for the best, at this point. Let me know if anything else is still broken. |
There are some Windows related build issue:
It looks mkdir only takes one parameter in Windows. |
I can build the exe file (The Debug target in Code::Blocks project) When I run the target, it gives such command line messages:
Maybe, the path is different with Linux and Windows. My question is: Is it possible to simply let the parser parse a single header file. Such like:
|
I can throw one together this evening for you to play with. As long as you only need C++03, you should see decent results. The target you're building is configured to parse a specific project of ours, and so it defines include directories and macros specific to that engine. |
I cut the general parts out of the old main and into a new one under a new "Demo" build target (dcdce97). I am not certain it will build for you, but I've done my best on that front. I threw in a macro that preprocesses away
...ignoring a CLI quirk in switching from Cheers |
Thanks. This patch is need because Windows only have
Also, I think this patch is also needed
|
Oops. I created a And yes, at some point, I should merge the logic here with that in our original Is |
Under Windows, there is no such command(tool):
Is there any way I can print/view the whole parsing tree? Here is my log, which seems correct, but I'd like to check how the parser is parsing a simple file:
This is my test.h file:
|
You want the |
See here: linux - What is a cross-platform compatible way to redirect to NUL or /dev/null? - Stack Overflow Under Code::Blocks' source code, we use something similar like:
|
Ah. Well, you can also just populate search dirs manually the same way the functions in that routine does. Our game engine also has that info lying around, which is why I never moved it into the API. |
And before you ask, here's a breakdown of some oddities you'll see in the output:
The argument types aren't known (parsing error).
The types are kind of known (they're dependent types).
Printing error (not so pretty print I hacked together for inspection). Also probably a few thousand parse errors in general. Some from missing features, some from bugs. Working on it, slowly. |
I see a build error when building the demo target, see this log
It looks like this is caused by a GCC 10 version under msys2? |
Perhaps moving |
Yes, this fixes the build issue, thanks for the help!
I just create a simple test code like below:
And it builds OK without any issue.
|
It looks like this command does not dump everything, it just print the namespace. I have this code to be parsed:
Then here is the command result:
Does this command only print the namespace recursively? It does not print the symbol |
Ugh. No, sounds as though I've broken something. I haven't finished integrating the newly-merged master with our own codebase yet, so not terribly surprising I missed something in my cursory inspection. What's odd is that I confirmed the system recognized our own structures, so perhaps this is a recent regression I didn't think to look for. I'll get some unit tests added for this and we can hopefully avoid this problem in the future. Thanks for the update! |
Yeah, it was a regression. While I was replacing all JDI's internal pointer types with I've gone ahead and merged it into master. No sense turning back, at this point. |
OK, It now print the member function. Good work! BTW, I have a lot of changes in my local copy against the master HEAD. Which make the cbp build under Windows(I'm using code::blocks + Msys2) Here is first patch:
|
This is the second patch, which comment out the signal function under Windows. I think we need a #if here?
|
The third patch.
|
The forth patch, I have to use a type cast operator to make the compiler happy.
|
Now the patch for the cbp file, I just disable the compiler option
Also, another changes which make the compiler happy
|
There is nul under Windows which is different than Linux
BTW: I see that in today's rebase, you have change some dev_null string in other place by a |
As you suggested, I have put the llreader.h in the first place of the cpp file, which fix the build error.
|
I see another build error here:
It looks in such line
Any idea how to fix this build error, I have to comment out the part after the workaround:
|
The compiler you're using seems to have some serious problems... that, or Windows has reserved Thanks for the patches! I'll apply them tonight. Might be easier to just commit them to a local fork and drop a pull request. Or I can give you access to push them as a branch, if you like. |
I can start a pull request, but I think a lot of my patches should be modified, because it will break the Linux build. That's the reason I post the patch contents here in the comments. |
Ah, I understand. Nope, don't worry about it. I'll update the code around the patched areas to use newer C++ features instead of relying on platform-specific code. Looks as though most of these patches are for things covered by std::filesystem, or small oversights my compiler doesn't care about. Thanks for the pointers! |
One question: why does your implementation not support Is it just the SIGTRAP macro? I can replace it with 3. |
Yes, it is just SIGTRAP macro. See the build error:
|
Still haven't figured out that header order problem. I think maybe you need to enable STL debug mode to reproduce it, but I still think it's the include order of Regardless, the include belongs at the top of the file, anyway, and I've applied those patches or a similar fix and created #21 to merge them. I am hoping that branch will build for you without error. It might be good to have a dump of all the compiler warnings so I can take a crack at those, but I'm sure I'll generate more when I go to add support for parameter packs and decltype. |
I'm building the |
Excellent. Also, fundies went ahead and added a MinGW build to the CI, so we should be able to avoid future breakages that way. |
I have msys2, and have its 64bit GCC compiler install.
When using the cbp file under Code::Blocks, I see some build errors, such as this one:
There are some other build errors, but let's fix them one by one.
The text was updated successfully, but these errors were encountered: