libucl 0.8.0 release is pretty broken on Windows 10 + Visual Studio 2015 Community edition

[gafferongames]

Using CMake I am able to build the libucl.sln file for 0.8.0 but actually building the source seems out of the question. 100s of errors and warnings. Is Windows a supported platform?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/35495455-libucl-0-8-0-release-is-pretty-broken-on-windows-10-visual-studio-2015-community-edition?utm_campaign=plugin&utm_content=tracker%2F483345&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F483345&utm_medium=issues&utm_source=github).

[denisvm]

Hello @gafferongames, have you tried compiling it with Cygwin? I've managed to compile it fine using cmake inside Cygwin:

mkdir build
cd build
cmake ..
make

[questor]

I've got it compiling and running on win+vs2015, but it's hacky and I had to disable one feature (setting the directory variable automatically). and currently it's not correctly integrated into the buildsystem. if it's helpful for you I can provide you the patches here, but I don't want to create a pull-request because of the missing functionality...

[kyokke-viola]

Hi @questor , I am interested in your patch for vs2015. Could you provide me with the patch?

[questor]

sure:

• in "ucl++.h" I'm not sure if I have added #include in the header
• in "mum.h" remove the typedefs for msvc (vs2015 already knows the types)
• in "utstring.h" add below the other includes add the following block:

#include <stdint.h>

#ifdef _MSC_VER
#include <BaseTsd.h>
typedef SSIZE_T ssize_t;
#endif

• I've used the following config.h file, but I think it can be cleaned up further:

#define HAVE_FLOAT_H 1
#define HAVE_MATH_H 1
#define _WIN32 1
#define HAVE_CTYPE_H 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_FCNTL_H 1

#include <io.h>

#if defined(WIN32) || defined(WIN64)
    // Copied from linux libc sys/stat.h:
    #define S_ISREG(m) (((m) & S_IFMT) == S_IFREG)
    #define S_ISDIR(m) (((m) & S_IFMT) == S_IFDIR)
#endif

#ifdef _MSC_VER 
//not #if defined(_WIN32) || defined(_WIN64) because we have strncasecmp in mingw
#define strncasecmp _strnicmp
#define strcasecmp _stricmp

#include <stdlib.h>
#define PATH_MAX _MAX_PATH

#endif

• in ucl_util.c do the following changes:
• at the top include the following:

#include <stdint.h>
#ifdef _MSC_VER 
char *basename(char *path) {
  char *res;

  // Skip drive letter
  if (path[0] != '\0' && path[1] == ':') {
     path += 2;
  }

  // Return pointer to the char after the last directory separator
  res = path;
  while (1) {
     char c = *path++;
     switch (c) {
     case '\0':
        return res;
     case '\\':
     case '/':
        res = ++path;
        break;
     }
  }
}
#endif /* _MSC_VER */

and in "ucl_parser_set_filevars" comment two lines and add a todo-message:

// curdir = dirname (realbuf);
// ucl_parser_register_variable (parser, "CURDIR", curdir);
ucl_parser_register_variable (parser, "CURDIR", "CURRENTLY_NOT_IMPLEMENTED");

[kyokke-viola]

@questor ,

Thank you for your immediate response! I applied your patch and make sure that i can build ucl.lib on msvc2015.

As you stated above, disabled function "ucl_parser_register_variable()" is not trivial. I added a following snippet just after declaration of basename function in ucl_util.c :

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
char *dirname(char *path)
{
    char drive[3]; 
    char dir[512]; // TODO : use appropriate constants macro 
    char val[512]; // TODO : use appropriate constants macro 
    _splitpath(
        path,
        drive, // drive
        dir,   // dirname
        NULL, // doesn't use filename 
        NULL  // doesn't use ext
    );
    sprintf(val, "%s%s", drive, dir);
    return strdup (val);
}

As for now, I have just confirmed a test program "test_basic" can generate outputs for all of tests/basic/*.in except than 13.in. (13.in is test for "glob function" which is disabled for windows so it is not a problem)

[odiszapc]

@kyokke-viola @questor Please find out my PR: https://github.com/vstakhov/libucl/pull/166