[NO_MERGE] Build on windows #8290
Conversation
YongseopKim
added
PR/NO TEST
|
Anyway, building is successful. |
| @@ -124,7 +124,7 @@ bool substitute_strided_slice_to_reshape(luci::CircleStridedSlice *ss_node) | |||
| std::bitset<32> end_mask(ss_node->end_mask()); | |||
| std::bitset<32> shrink_axis_mask(ss_node->shrink_axis_mask()); | |||
|
|
|||
| uint input_rank = input_node->rank(); | |||
| uint32_t input_rank = input_node->rank(); | |||
| if(EXTRACTION_ERROR) | ||
| message(FATAL_ERROR "Extract ${PREFIX} - failed") | ||
| endif(EXTRACTION_ERROR) | ||
| # TODO: |
| @@ -180,9 +181,16 @@ int entry(int argc, char **argv) | |||
|
|
|||
| if (arser.get<bool>("--verbose")) | |||
| { | |||
| #if defined(__MINGW32__) | |||
There was a problem hiding this comment.
It would be helpful if you add a comment that explains why you added this codes.
There was a problem hiding this comment.
Actually we have never used compiler directives in our compiler frontend.
And I hope not to use them afterwards.
Reason: These make code readability hard and also development hard.
There was a problem hiding this comment.
I understand your points :-) I'll make a draft for this with a detailed explaination.
There was a problem hiding this comment.
Ah, before the draft, let me explain shortly.
from https://sourceforge.net/p/mingw/mailman/message/35495004/
-
MSVCRT.DLL exports putenv(), (strictly _putenv(), but MinGW defines
an import library alias with the POSIX.1-2008-XSI compatible name),
which is semantically similar to the Unix System V function of the
same name. However, there is no setenv(), nor any semantically
similar API, provided by any Windows DLL. -
Neither putenv(), nor setenv() is required by ISO-C, so, even
though both are specified by POSIX, it isn't considered imperative
for MinGW to provide what isn't already provided by MSVCRT.DLL.
The points are
- setenv() is not implemented in MinGW because MinGW supports ISO-C spec.
- putenv() can be used instead of setenv() (actually putenv() <- _putenv())
While building on windows, I've faced these problems.
/cc @mhs4670go and @seanshpark
There was a problem hiding this comment.
Before the draft, we need to discuss
- how much do we contribute to building on windows. I personally prefer working on windows env so I'm doing this task. But, ONE officially doesn't support Windows. How much do we contribute to windows? (of course, I can contribute this as a personal developer NOT an official ONE developer.)
- Anyway, if I do this task, how to do it? @llFreetimell suggests making a new directory like
WinUtiland wrapping functions likesetenv().
There was a problem hiding this comment.
I think would be better to post a separate issue for this --> #8308
There was a problem hiding this comment.
Besides supporting for Windows, I don't think I will accept codes using like #if defined(__MINGW32__). As I wrote, introducing this one will eventually permit codes like this and that will lead to hell. (which I had experienced long time ago that I don't want to experience again)
You can consider supporting multi platform as, provide PAL (platform adaptation layer), detect/select platfrom from CMake.
| @@ -33,7 +33,7 @@ | |||
| #include <sstream> | |||
| #include <string> | |||
| #include <vector> | |||
| #include <cstdlib> | |||
|
If mingw and linux have mutually exclusive things, it is good to use
|
Just try. Do not merge. /cc @mhs4670go