about building on Windows again, TextMagus CMake use for generating MSVSC++ project for TextAdept

[dr-dba]

As we all know, there is no "out of the box" .vcporj for MSVC++ Studio.
That is a rather sad thing.
Thinking about it, i come upon this aged TextAdept fork, with CMake!
https://github.com/textmagus/textmagus
https://github.com/textmagus/textmagus-3rdparty-textadept
it was not dedicated to VC++, but there is a "CMakeLists.txt"
So, i tried to run cmake, and it worked. Partially.
It compiled indeed, created succesfully:

• scintilla_lexlib.vcxproj
• lua_filesystem.vcxproj
• tre.vcxproj
• lua_lpeg.vcxproj
• lua.vcxproj

But textadept.vcxproj itself were not created..
cmake said about GTK not found:

-- Some or all of the gtk libraries were not found. (missing: GTK2_GTK_LIBRARY GTK2_GTK_INCLUDE_DIR GTK2_GDK_INCLUDE_DIR GTK2_GDKCONFIG_INCLUDE_DIR GTK2_GDK_LIBRARY G
TK2_GLIB_INCLUDE_DIR GTK2_GLIBCONFIG_INCLUDE_DIR GTK2_GLIB_LIBRARY)
-- WARNING: did NOT find GTK2 -- disabling

But, does windows building need GTK ??
From my understandig, do not need (?), just CMakeList.txt is wrong about it.
this CMakeLists.txt can be probably fixed?
here is the link to CMakeList.txt:
https://github.com/textmagus/textmagus/blob/master/CMakeLists.txt
the TextAdept CMake project repository:
https://github.com/textmagus/textmagus

Can it be helped?
I am not very good at fixing cmakelists files..

P.S.
I need to explain my interest i am pursuing to build on Windows with MSVC++.
I know "TextAdept Windows builts is not supported",
and i do not know much about building for windows in docker either
Because, currently MSVC++ it is the only build tool i know,
and can be used for debugging.
And i intended to play with TextAdept developing in C++.
CMake, given proper CMakeList config file,
takes care of converting code to .vcproj (MSVC++ project),
and this allows building and debugging in MSVC++

[orbitalquark]

Yes, Textadept depends on the cross-platfrom GTK GUI toolkit. I don't know hardly anything about CMake. Building for Windows is currently only supported using Docker, as mentioned in the README.

[dr-dba]

Ok, so also on Windows GTK is needed, right?
Why i asking, because from here,
one can get impression that on Windows it does not required:

In its bid for minimalism, Textadept depends on very little to run.
On Windows and macOS, it has no external dependencies.
On Linux and BSD, the GUI version depends only on [GTK]
(a cross-platform GUI toolkit) version 2.24 or later

"On Windows .. it has no external dependencies"

[dr-dba]

I need to explain my interest i am pursuing to build on Windows with MSVC++.
I know "windows builts is not supported", and i do not know much about building for windows in docker either
Because currently it is the only build tool i know and can use for debugging.
And i intended to play with TextAdept developing in C++, so ..

[orbitalquark]

Run-time dependencies is different from build-time dependencies. Textadept has no run-time dependencies on Windows. You can run the application you downloaded without having to install anything else. This is what is meant by "external dependencies". In order to build the application, you will need things. When building with Docker, `make deps` takes care of fetching those things.

[dr-dba]

Well, so seemingy, i need to fetch GTK distribution..
Should i look at where docker script fetching it,
either i can use any other GTK?
Need it be windows-specific GTK, either just grab any recent *nix distribution?
Let's say, here is "GTK for Windows", is it good for us?
https://sourceforge.net/projects/gtk-win/files/GTK%2B%20Runtime%20Environment/GTK%2B%202.24/

[orbitalquark]

Try this: https://github.com/orbitalquark/textadept-build/blob/default/win32gtk-2.24.32.zip. That link you posted is a run-time only (just contains dlls and such; no source files for compiling against).

[dr-dba]

Thanks!
i digged thru all the internet searching for,
while missing to seek in here :)

Yess, there is compiled stuff without headers and dev stuff,
and, just curiousity, there is the source code from which it built,
can it be used, supposing someone missed again "textadept-build" repository?
https://sourceforge.net/p/gtk-win/code/HEAD/tree/

[orbitalquark]

Sorry, I don't understand the question. The textadept-build repository is relatively new since Textadept only recently moved to GitHub.

[dr-dba]

well, finally i managed to generate VS projects to all, also for TextAdept.
i combined the GTK2 from textadept-build, but together with other's GTK2 repositories,
because for example, pkg-config was required, and a bunch of other headaches on the way.

[dr-dba]

The problem now in gt_dialog:

this is the only error, everything other is fine,
just keep saying kind of "cannot allow declaration with variable length", but why?
may you know how to fix?

[orbitalquark]

What version of Visual Studio are you using? It looks like the C compiler does not support variable length arrays. Microsoft has always been lagging behind on supporting C standards, while MinGW has been fine.

[dr-dba]

VS 2019, with all possible c-related components installed.
The latest, AFAIK. BTW:

[orbitalquark]

That "C Language Standard: Default (Legacy MSVC)" setting looks problematic. If you could change it to something more modern, that would help. Otherwise, you'll have to modify gtdialog to malloc and free based on nrows.

[dr-dba]

I was also toward that thinking abt, and changed the Legacy to all other options to test,
which are: C++ std 14, and C++ std 19, right now i cant send printscreens,
but anyway that is not that.
The abiltity to compile arrays with variables defined it's size,
looks like some (not standard?) extension of C++ indeed, which is not supported still by VS 2019.
VS supports "C++ std 14/17/19 (experimental)"
(a bit later today i can send exact VSC++ supported standards)

[dr-dba]

Microsoft has always been lagging behind on supporting C standards,
while MinGW has been fine

I like MingW, i have it installed, i guess i can compile many things there,
together this does not help regarding the purpose to have proper debugging,
to see how all the things work and connected between.

Many of developers people have a good opinion abt VS C++ dev features..
is it really so retarted ?

Ability to use VS will save a huge amount of time to me,
instead of learning som over C++ dev. enviroment,
although i am not a big fan of Microsoft by any means,
but by historical reasons i am from MS background

[dr-dba]

Ok, i understand now that is abt VLSes, V(ariable)L(ength)A(rrays),
which is prohibited in VS, and can be allowed or denied in other compilers.

meanwhile this solution looks promising.
Instead of:
GtkWidget *entries[nrows];
it seem this will work:
IGtkWidget** entries = malloc(sizeof(GtkWidget*) * nrows);
please check it for correctness ?

gtdialog_gtk2 was build succesfuly, going to test that ..

[orbitalquark]

That looks fine. Ideally that memory would also be freed in the end in order to avoid memory leaks. However, if you're not using multi-line input dialogs, then you don't have to worry about it.

[dr-dba]

Well, no luck meanwhile, new day, new problems:

[dr-dba]

That looks fine. Ideally that memory would also be freed in the end in order to avoid memory leaks. However, if you're not using multi-line input dialogs, then you don't have to worry about it.

I will definetly eliminate any memory leaks, but i am currently hard to believe i can overcome all that stuff

[orbitalquark]

It looks like your linker flags are not set properly (e.g. "-L/path/to/libiconv -liconv"). Normally pkg-config provides those flags. I don't know how you set up your include flags, but you'll have to do something similar for your linker flags and point them to the dlls in the *win32gtk/bin/* directory.

[dr-dba]

WOW.
now i've fixed iconv.lib, and have only 50 compile errors, that is less 3 than before.

[dr-dba]

And this time i really have no idea.
iconv problems was solved by adding manually iconv.lib to VS linker,
which happened to be in here: F:\GTK\GTK2-Runtime\lib
and there is a good plenty of other .lib's.
And now i wander which exactly .LIB,
i need to choose and provide to linker there?
here is all the stuff:
art_lgpl_2.lib, asprintf.lib, atk-1.0.lib, bz2.lib, cairo.lib, charset.lib, croco-0.6.lib, expat.lib, fontconfig.lib, freetype.lib, gailutil.lib, gdk-win32-2.0.lib, gdk_pixbuf-2.0.lib, gdkglext-win32-1.0.lib, gio-2.0.lib, glade-2.0.lib, gladeui-1.lib, glib-2.0.lib, gmodule-2.0.lib, gobject-2.0.lib, gsf-1.lib, gsf-win32-1.lib, gthread-2.0.lib, gtk-win32-2.0.lib, gtkglext-win32-1.0.lib, iconv.lib, intl.lib, jpeg.lib, libpng.lib, pango-1.0.lib, pangocairo-1.0.lib, pangoft2-1.0.lib, pangowin32-1.0.lib, png.lib, popt.lib, rsvg-2.lib, tiff.lib, xml2.lib, z.lib, zdll.lib

I would expect to see there smtg like "GtkWidget.Lib",
but there is not, ad not in any other place

[dr-dba]

I have got such command lines in VS:

[dr-dba]

.. with the same results of 50 coompile errors :(

[orbitalquark]

On Thu, 18 Feb 2021 15:05:55 -0800 Xer0X ***@***.***> wrote: And this time i really have no idea. `iconv` problems was solved by adding manually `iconv.lib`, which happened to be in here: `F:\GTK\GTK2-Runtime\lib` and there is a good plenty of other .lib's. And now i wander which exactly .LIB, i need to choose and provide to linker there? here is all the stuff: `art_lgpl_2.lib, asprintf.lib, atk-1.0.lib, bz2.lib, cairo.lib, charset.lib, croco-0.6.lib, expat.lib, fontconfig.lib, freetype.lib, gailutil.lib, gdk-win32-2.0.lib, gdk_pixbuf-2.0.lib, gdkglext-win32-1.0.lib, gio-2.0.lib, glade-2.0.lib, gladeui-1.lib, glib-2.0.lib, gmodule-2.0.lib, gobject-2.0.lib, gsf-1.lib, gsf-win32-1.lib, gthread-2.0.lib, gtk-win32-2.0.lib, gtkglext-win32-1.0.lib, iconv.lib, intl.lib, jpeg.lib, libpng.lib, pango-1.0.lib, pangocairo-1.0.lib, pangoft2-1.0.lib, pangowin32-1.0.lib, png.lib, popt.lib, rsvg-2.lib, tiff.lib, xml2.lib, z.lib, zdll.lib`

Why not try manually adding all those libs too?

[dr-dba]

yes, correct, i sent print screens, but i would better like say it more explicitly too.
I added manually, as it appears in compiler command lines i printscreened.
Not helped much though

I currently trying to go check up with this direction:
https://gtkmm.org/en/
As if, there are in GitHub examples for VisualStudio based on it.
What do you think about, can it help?

[orbitalquark]

Oh, sorry, I misunderstood. I honestly do not know why these errors are still occurring. There isn't a GtkWidget.lib because the GTK widgets should all be in gtk-win32-2.0.lib. This is why compiling on Windows has been unsupported -- I don't know much of anything when it comes to building on the platform :(

[dr-dba]

Well, right now i got the libraries right, the problem was about confusing your ".dll.a" named libs, with foreign ".lib" named libs.
The linker's command line should be:

/OUT:".\Debug\textadept-gtk2.exe" /MANIFEST /NXCOMPAT /PDB:".\Debug\textadept-gtk2.pdb" /DYNAMICBASE ".\Debug\gtdialog_gtk2.lib" ".\Debug\lspawn_gtk2.lib" ".\Debug\lua.lib" ".\Debug\lua_filesystem.lib" ".\Debug\lua_lpeg.lib" ".\Debug\scintilla_gtk2.lib" ".\Debug\scintilla_lexlib.lib" ".\Debug\tre.lib" "libasprintf.dll.a" "libatk-1.0.dll.a" "libcairo-gobject.dll.a" "libcairo-script-interpreter.dll.a" "libcharset.a" "libcharset.dll.a" "libexpat.dll.a" "libfontconfig.dll.a" "libfreetype.dll.a" "libgailutil.dll.a" "libgdk-win32-2.0.dll.a" "libgdk_pixbuf-2.0.dll.a" "libgio-2.0.dll.a" "libglib-2.0.dll.a" "libgmodule-2.0.dll.a" "libgobject-2.0.dll.a" "libgthread-2.0.dll.a" "libgtk-win32-2.0.dll.a" "libiconv.dll.a" "libintl.dll.a" "libpango-1.0.dll.a" "libpangocairo-1.0.dll.a" "libpangoft2-1.0.dll.a" "libpangowin32-1.0.dll.a" "libpixman-1.a" "libpng16.dll.a" "libz.dll.a" "libcairo.DLL.A" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /DEBUG:FULL /MACHINE:X86 /SAFESEH /PGD:".\Debug\textadept-gtk2.pgd" /SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:".\dbg_int.dir\Debug\textadept-gtk2.exe.intermediate.manifest" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\GTK\GTK2-Runtime\lib" /TLBID:1

[dr-dba]

So, the textadept-gtk2.exe successfully compiled. hurrah.
and happily gives this error:

textadept-gtk2.exe - Entry Point Not Found
The procedure entry point g_module_close could not be located in the dynamic link library libgdk-win32-2.0-0.dll.

Any ideas?

See, if we will solve the MSVSC++ build,
this will attract a great many of TextAdept adepts and supporters :)

P.S.
The problem is, probably related to modern libraries of win32gtk-2.24.32.zip and aged sources of TextAdept, which was taken from TextMagus repository. I will be able to check that out a bit later.
That is to say, take the modern latest this, and modern latest that, and see.

[orbitalquark]

That's weird. `g_module_close` should be in libgmodule-2.0.dll, which it looks like you've linked. I don't know why it's looking in the libgdk-win32 DLL.

[dr-dba]

Strange indeed. it cant find g_module_close in Libgmodule-2.0.dll, and goes to first other library.
for example, if i put LibGTK before LibGDK, it will sau the same error but about LibGTK this time.

[dr-dba]

Well, i fighted some disasters, and have had some advances
Fixed a great many thing, to only discover there is another better, and proper way(s) to do it.
Learned a lot, and wasted time even more.
(Sad, but true, there is no other way to work it out for mediocr techie like me :)
Someday i will complete the full proper path to get there.
In general:
1.) it seems to be possible integrate MSVC with Msys/MingW and still have proper MSVC debug
2.) There is a few half worikng projects for GTK/GLib in MSVC,
probably the most working of them is this:
https://github.com/codekiddy2/Visual-Studio-gtkmm/
3.) You can find in old releases of oficial GTK/GLib MSVC stuff,
which was dropped relatively recently, about middle of 2017-2018
(that was nasty of them, cause you do not see something relevant to MSVC in their latest releases)

BTW, if you know relevant C/C++ dedicated forum,
related to this, or near to this topic,
you are welcome to recomend it, thanks

[orbitalquark]

That sounds like quite the adventure, and probably the reason why I only ever bothered cross-compiling from Linux. I don't know any C/C++ programming forums, sorry.

[dr-dba]

Thank you for caring, that is a hard stuff really.
Out from curiosity, may i ask,
Being originally not C-developer (? i guess),
how much you fighted with the C\C++ stuff for TA?
Integration with Lua and scintilla, those libraries, and so on.
Either you were helped for that mostly?

[orbitalquark]

Fortunately the only part of Textadept that is C++ is Scintilla and its lexers. I try and avoid that area of the code as much as I can. I've learned more C++ over the years, but I'm still pretty uncomfortable with it. I mostly learn by trial and error and using existing examples. For example, reading Scintilla's makefile helped me build Scintilla into Textadept, and reading Scintilla's C++ lexers helped me build the Scintillua lexer.

[dr-dba]

I would also be very happy not to touch that area, honestly.
The problem is and when i want to join the things together.
Thats looks simple, to build GTK/Glib,
publishers also should be interested in proper cross-platforming.
many people and companies did it, right?
Probably did, but not cared enough to share it publicly.
And all kinds of problem on the way to:
"just take a ready established project and debug it for your pleasure"
This makes me kind of crazy about ..

A little example (of hundreds i had met)
I was recommended to take Mozilla-Build enviroment,
("only this is a proper way to compile LibFFI")
I downloaded it installed. And there are no autotools. How it come?
Well, there is a very hidden package on the net, "wintools",
something to do with the problem, right? (wrong)
well, i downloaded all downloadable from the net,
read all the documentation abt MozillaBuild, there is no much of it,
about 10 long articles, still takes time to digest..
Nothing related to autotools! :) (automake, libtool, autoreconf, make, etc)
Well, i realized them removed it from v3.0,
and that insistent advice to build LibFFI with MozillaBuild was abt v2.0+
and this happens on every little step.
Makes an impression nothing in reachable GitHub/open-source related to C++ will not do and should not do.
Of coz, I am talking abt professional C/C++ products and people,
not abt "amateurs" C/C++ products like you.

You are thankfully responding and cooperating,
that is why i still want to defeat MSVC hurdles

[dr-dba]

Is flag /SAFESEH required for correct build?
either it is optional, either does not matter too much?
Probably there are some libs which cant be compiled with SAFESEH,
and so preventing the TA too from using SAFESEH

[orbitalquark]

Sorry, I don't know the answer to that. You'll have to experiment.

[dr-dba]

Well, right now it looks a little bit better :)

the answer was, *.dll.a are libraries only good for MingW, and MSVC doesnt like it.
It seems to be possible to take MingW DLLs and build .libs from it,
but, i am not sure, is it really need?
I took ready dlls+libs of GTK2.24 for MSVC, guess from where, from WayBack machine:
https://web.archive.org/web/20150905072710/http://www.gtk.org/download/win32.php
Not too much other remnants over all the internet. The bright side of the story, though,
is what i became an owner of most complete collection in the world of GTK+2.24 various pieces

[dr-dba]

I cant resist to demonstrate the exact meaning and purpose, having proper IDE:

The thing is obviously got broken, but, see how easy you can take on it

[dr-dba]

[orbitalquark]

Yay! Well done :)