Windows compatibility

[mittinatten]

Some C99 and GNU constructs aren't compatible with the MS C compiler. Code should be harmonized. (discussion started at bp-kelley@126df0a)

Known issues

• Remove variable length arrays
• Redefine restrict keyword if Microsoft compiler detected
• Optional header unistd.h in lexer.c can be excluded
• Redefine inline keyword if Microsoft compiler detected
• Redefine __func__ if not defined
• Add _USE_MATH_DEFINES
• Remove GNU getline dependency

Other tasks

• Look into CI tools for Windows (AppVeyor)

Work is done in branch windows (https://github.com/mittinatten/freesasa/tree/windows)

[mittinatten]

Ok @bp-kelley, I have removed the VLAs I could find and redefined restrict in the windows-branch. I couldn't find a compiler flag to turn off VLAs without turning off a bunch of other stuff, so there might be a few that I missed. I also added something for _USE_MATH_DEFINES in the affected files.

For restrict I used

#ifdef _MSC_VER
#define restrict __restrict
#endif

I'm not sure if _MSC_VER is the most appropriate variable to check for?

[mittinatten]

I think I solved the issue with unistd.h in lexer.h in 9b64828. I just needed to upgrade to a newer version of flex and use the flag --nounistd. The generated files are included in the repo.

[bp-kelley]

That should work fine for all the versions of windows you are likely to see, but for full backwards compatibility you could do

#if defined(_MSC_VER) && _MSC_VER >= 1400
  #define restrict __restrict
#else
  #define restrict
#endif

AS I think __restrict was added in version 1400

[bp-kelley]

@mittinatten let me know when you want me to try a windows build. I'll pull this into my fork and add an appveyor windows build script.

[mittinatten]

Hi,
I have added all the modifications I am aware of are necessary in the branch 'windows'. There is one spurious error that occured today in one of the tests but didn't yesterday, so I guess it's a buffer overflow or something that by chance didn't have any consequences yesterday, but I think I can work on that in parallel. So whenever you have time to look at AppVeyor integration, just go ahead!

Simon

[mittinatten]

Hi again @bp-kelley,
I solved the spurious error, it wasn't related to any of this, but a test that was too big and timed out. My computer is simply getting slower. I pushed a fix to dev.

[bp-kelley]

Great! Here is my current plan: 1. Work on getting the rdkit integration with FreeSASA working again and tested on Linux/OS X/windows 2. With your permission, I'll either add a visual studio project file or a cmake make file to build on windows, this will require a getline implementation which may take a little while.

…

---- Brian Kelley

On Jun 8, 2017, at 2:08 PM, Simon Mitternacht ***@***.***> wrote: Hi again, I solved the spurious error, it wasn't related to any of this, but a test that was too big and timed out. My computer is simply getting slower. I pushed a fix to dev. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mittinatten]

Sounds good!

1. Just let me know if there are any problems
2. Sounds fine, as long as the footprint can be kept small: If possible have configuration scripts write to config.h, and reuse as many of the flags there as possible, etc. (i.e. avoid if (USE_JSON || MSC_USE_JSON) ...). Getline is a problem, and I was hesitant to use it to begin with (but it's just very convenient). A custom one would have to be conditionally linked, as I'd prefer to keep the GNU implementation when available.

I'm soon heading for vacation, but will be back in July, just so you know why correspondence might be a bit sparse.

[bp-kelley]

Thanks for the reply. I'll work on the RDKit integration first and then extend. I'm also out until July as well.

…

On Fri, Jun 9, 2017 at 3:45 AM, Simon Mitternacht ***@***.***> wrote: Sounds good! 1. Just let me know if there are any problems 2. Sounds fine, as long as the footprint can be kept small: If possible have configuration scripts write to config.h, and reuse as many of the flags there as possible, etc. (i.e. avoid if (USE_JSON || MSC_USE_JSON) ...). Getline is a problem, and I was hesitant to use it to begin with (but it's just very convenient). A custom one would have to be conditionally linked, as I'd prefer to keep the GNU implementation when available. I'm soon heading for vacation, but will be back in July, just so you know why correspondence might be a bit sparse. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJbioEYJntzWqY6mqjvg0prsm1UQdzysks5sCPgbgaJpZM4NwYs7> .