build: tweak the build target on CIO_BACKEND_FILESYSTEM=Off

[fujimotos]

This is a series of patch to make compilation on Windows easier.

344e18b build: do not build tools/cio if CIO_BACKEND_FILESYSTEM=Off
74ed9d2 build: also don't build "cio_utils.c" if CIO_BACKEND_FILESYSTEM=Off

Part of fluent/fluent-bit#960

[edsiper]

hi,

the tools system must be always enabled due to the following reason:

• performance test: even if using memory only backend is important to be able to test read/write performance with different modifiers such as the checksum. This is a way to let the user test in isolation the better setup for them.

[fujimotos]

the tools system must be always enabled due to the following reason:

OK. Then I'll work on it so that we can run the perf test on Windows.

I think we need to get two things straight for that goal.

1. Windows does not have getopt_long(), so we need to polyfill it.

2. Functions in cio_utils.c are by and large not portable.
   We need to reimplement them using Win32 API.

For (1), we can probably make use of some existing implementation.
Here is a draft patch I created based on the one from musl libc (which
is MIT-licensed).

master...fujimotos:sf/getopt

What is your feeling about this? If you know a better alternative,
I will switch to it.

[edsiper]

so likely fluent-bit.c will face the same issue, what other projects are doing to solve the options/arguments stuff in Windows ?

[cosmo0920]

• spamassasin implements getopt their compatible functionality on Windows: https://github.com/apache/spamassassin/blob/b3eec151acfcc5f7f6d7f6528e41150218094d2b/spamc/getopt.c
• Microsoft provides getopt compatible in iotivity project: https://github.com/iotivity/iotivity/blob/master/resource/c_common/windows/src/getopt.c
• And many projects implement getopt in their own ways: https://github.com/search?q=windows+getopt

[fujimotos]

@edsiper For a cross-platform project originating from Unix world,
there seem to be two options.

1. Implement own command-line option parser (git/vim/cmake etc.)
2. Use a Windows-compatible getopt implementation (libevent etc.)

As to the first way, these projects essentially iterate args manually,
and throw a bunch of string comparisons. So they are quite portable
and don't require any platform-dependant fix.

https://github.com/git/git/blob/master/git.c#L124
https://github.com/vim/vim/blob/master/src/main.c#L1823

As to the second way, I see libevent contains a Windows compatible
implementation of getopt_long() (seems like grafted from somewhere
else, and not fully GNU/getopt compatible, though). Here is the code:

https://github.com/libevent/libevent/tree/master/WIN32-Code

I'm inclined to choose the option 2, mainly bacause chunkio and fluent-bit
uses getopt_long() already. This means we do not need no rewrite the
option parsing logic in main() for Windows compatibility.

[edsiper]

thanks for the info. Looking around I've found that I've placed a getopt() clone in Monkey mk_core interface here:

https://github.com/monkey/monkey/tree/master/mk_core/external

since the bits are in place, we just need to add a getopt_long() clone to it as a new file, we just need to be careful about the license.

[fujimotos]

https://github.com/monkey/monkey/tree/master/mk_core/external

OK. I go add a clone of getopt_long() there.

we just need to add a getopt_long() clone to it as a new file, we just need to be careful about the license.

Since several implementations are available, I'm going to investigate which clone is
preferable for our use case (incl. License), and do some testing on Windows.

Anyway, thanks for your review and comments. I'll close this ticket now.

[fujimotos]

@edsiper I can confirm that we can run tools/cio on Windows
with the remaining #30, #31, #32, #33, #34, #35 and #36 merged,

I think chunkio is basically done porting, and we can bring the merged
HEAD to fluent-bit.