Build Error in Visual Studio 2019

[ghost]

I am getting the following trying to build the MSVC link grammar project, on which the others depend:

Severity Code Description Project File Line Suppression State
Error C1083 Cannot open include file: 'regex.h': No such file or directory LinkGrammar C:...\link-grammar-5.9.1\link-grammar\dict-common\regex-morph.c 27

I see in the docs that I need to create the regex library/dll. I do not see a dlltool app in CYGWIN, and the paths/files in the instructions for VS 2019 don't quite match the GnuWin32 install.

Thoughts?

[ampli]

I do not see a dlltool app in CYGWIN

It is /usr/bin/dlltool.exe, a part of the binutils package which is said to be installed by default (it contains the basic development programs). Try to search it with: cygcheck dlltool . You can use setup-x86_64.exe from the Cygwin site to check for the existence of binutils and install it if it is missing.

Note that you don't need dlltool if the regex package you install already contains the LIB file. You just need to rename the LIB/DLL files to regex.lib/regex.dll if they are not already named so.

and the paths/files in the instructions for VS 2019 don't quite match the GnuWin32 install.

In the msvc/README.md file, under Setup, you will find how to change the path of the installed location of the regex library (environment variable GNUREGEX or property GNUREGEX_DIR).

[ghost]

Making progress... Not there yet, but I'll document some things for the README.

The cygwin setup-x86_64.exe file skips binutils for some reason, even when initially installing all. I went back in and changed the "View" dropdown to Full. I found binutils and it was set to Skip in the New column. I selected the latest, clicked the Next button at the bottom right and was able to install it.

'cygcheck dlltool' in the console then showed it.

When installing Tre for Windows as linked from the docs, it wants to install at C:\Program Files (x86)\GnuWin The spaces, of course, will cause problems. I changed that to C:\GnuWin. When executing dlltool, since Windows uses the backslash for directory delimiting, and that is an escape character in Linux, the paths in the argument have to be delimited with '\\'. The following successfully created regex.lib (note tre.def is tre4.def):

dlltool -l regex.lib -d C:\\GnuWin32\\lib\\tre4.def -D regex.dll C:\\GnuWin32\\bin\\tre4.dll

I moved that to the Tre folder that has regex,h.

My environment variable is in System Variables (In Windows System Properties): GNUREGEX_DIR: C:\GnuWin32. I am thinking this is a Visual Studio environment variable? I have not had to work with these before. Guidance is appreciated.

[ampli]

I found binutils and it was set to Skip

So I guess it is not a default install after all, at least not now.

When installing Tre for Windows as linked from the docs, it wants to install at C:\Program Files (x86)\GnuWin

It seems I have downloaded one of the other files, which was a pure ZIP file (not EXE). It has the file names as shown in the README.

the paths in the argument have to be delimited with '\'.

A single forward slash works for me when performing this command from the Cygwin Terminal.

for the README

I now note that I somehow missed the Developer files download. It includes tre.lib!. So I will eventually update the README to use it and drop the reference to dlltool.

I moved that to the Tre folder that has regex,h.

The README says: which has the subdirectories include and lib and also The default is $(GNUREGEX_DIR)\lib.
However, it may not be clear enough that these files should reside under the lib directory (unless you change the corresponding definitions in the VS project property sheets).

My environment variable is in System Variables (In Windows System Properties): GNUREGEX_DIR: C:\GnuWin32.

GNUREGEX_DIR is the VS property sheet variable. The Windows system environment variable should have been:
GNUREGEX: C:\GnuWin32
(Maybe setting as VS environment variable would work too, but the point was to provide a local configuration way that avoids changes to the VS configuration).

After setting it, to check if it is properly set you can do from a CMD window:
set GNUREGEX
(I don't remember whether you need to restart the CMD window for that.)
When the GNUREGEX is set properly, you can start VS and it will use it.

[ghost]

OK, some interesting developments...

First, no matter what I did with the EVs for $(GNUREGEX_DIR) it was being forced to C;\Users[myname]\Libraries, which did not exist.

No matter what I tried to do in Windows 10 EVs, I could not repoint this. To verify, I would right click the LinkGrammar project and select Properties. In the Property Pages I'd select C/C++/General. At the top is Additional Include Directories. Selecting the dropdpwn and then Edit... shows the Additional Include Directories. There is a Macros>> button, Clicking it expands the dialog and you can scroll down to the GNUREGEX_DIR. It seems to always remain HOMEDRIVE+HOMEPATH, and those do not seem settable either.

So I created a Libraries/gnuregex folder and moved my GnuWin32 folder contents under it. VS wants to look in the /include folder for tre/regex.h so I made sure it was there. ThenI got an error looking for tre-config.h. It wanted it in ../link-grammar/dict-common, so I copied it there.

I was able to build successfully, albeit with a bunch of warnings.

What I want to do now is create a C# project that will call into this DLL. Any thoughts?

[ampli]

First, no matter what I did with the EVs for $(GNUREGEX_DIR) it was being forced to C;\Users[myname]\Libraries, which did not exist.

If you start VS by its icon, after verifying (in CMD) that the environment variable GNUREGEX is set properly, you may need to restart Windows so the GUI will pick it. However, you have already found a workaround so this is not needed now...

There is a Macros>> button, Clicking it expands the dialog and you can scroll down to the GNUREGEX_DIR. It seems to always remain HOMEDRIVE+HOMEPATH, and those do not seem settable either.

If you nevertheless would like to try to set GNUREGEX_DIR, do this:
View->Other Windows->Property Manager->LinkGrammar->release|x64->Local->Common Properties->User Macros. Then double-click on GNUREGEX_DIR and you will be able to change it (no need and no point to mark it as environment):

I was able to build successfully, albeit with a bunch of warnings.

Most or maybe all of them should be related to int and the like conversions. I didn't bother to fix them. On the Linux build and my private Windows build, they are just suppressed. If you see some other ones, it could be a good idea to fix them.

What I want to do now is create a C# project that will call into this DLL. Any thoughts?

Use SWIG. This is the way the python3 language bindings are implemented. As a start, you can copy the Python3 project and rename it to C#, then change it for invoking swig for C#. For the definitions, use bindings/swig/link_grammar.i (I guess you will need to add some definitions for C#; add them using #ifdef SWIGCSHARP).

However, if you just would like to use LG from within Excel cells (for example parse a sentence in a cell and get the result in other cells) it seems easier to build the existing Python3 project and write the desire Excel API functions using opnepyxl.