Testing FORM Project buildsystem to Crossmake

[TaiXeflar]

Though I'm a not knowing about this project too(have seen the translated news about the developers), but I think it actually can have more users and have more tests on cross-platform. So I give it a try on @tueda's fork #266 and make some changes that completly using cmake to build Form 4.2. I tested about a midnight and have some tested news here.

The bad news is half and half: The compiled form executable can't run check/example.frm and other original \*.frm form language sources. Actually tested that whatever ways to build(Meaning building on Windows, on Linux, or using automake to build) are failed to run check examples, but example codes in Cookbook can run.

The good news is it can actually run the FORM compiler build task on Windows 11and Linux(I don't have macbook so ignore it). Tested that MSVC(cl.exe) and Clang are successful to build with Ninja buildsystem, makes total compilation only 3~4 seconds.

Ready to share the result(CMakeLists.txt) and hope it helps!

Thanks TaiXeflar

PS: Screenshot on compile success and \*.frm form code test(If picture can show correctly)

[tueda]

Thank you for trying.

The compiled form executable can't run check/example.frm

I am not sure about which command you invoked to run the example, but if you run

/path/to/build/sources/form check/example.frm

and get

...
~~~Use -D TEST=XXX
...
Program terminating at check/examples.frm Line 1 -->
...

then it means FORM terminated as expected; you need to choose a test case by -D TEST=XXX when running outside the testsuite. Note that some test cases cannot work without POSIX.

IMHO, portability is nice and CMake can be a good choice, possibly with a package manager like vcpkg to handle the dependencies. Ideally, the Autotools build might be completely replaced by a CMake build in future, but this is not realistic in one go. What we can do is to add an optional CMake build while keeping the Autotools build working. Although your fork may not be compatible with the existing Autotools build (and moving "optional" files may upset a major part of practical users who run the threaded version of FORM on Unix), your work is a good starting point to discuss it.

[TaiXeflar]

The practice of "options" folder to step-by-step control files adding is consider list function(CMakeLists.txt) uses GLOB to call all the sources files inside the "sources". Doing this is quicker but may compile unexpected sources. Keeping all files at sources folder just change list(GLOB form_SOURCES ......), but needs list() of set() function in manual to set a compile list follows original Makefile.am SRCBASE.

set(form_SOURCES       
                    argument.c 
                    . 
                    . 
                    .)

And I will keep trying POSIX part on Linux test. Thanks a lot!

[tueda]

If we keep the list of source files in CMakeLists.txt which is the same as that for Autotools, then it violates the "Don't repeat yourself" principle and presumably becomes hard to maintain sooner or later.

Instead, my fork you mentioned has the read_automake_source function to read the list of source files from Makefile.am (though the implementation is ugly and painful to read).

https://github.com/tueda/form/blob/83184f8d00df387060885771d541ab6786215408/sources/CMakeLists.txt#L26-L55

[TaiXeflar]

I see. So I finally keep it as seprated status and continue watch if anyfiles may be lost(I uses Ninja to count the files many times). And I found the C/C++ flags has not been set(There's only debug build flags... or it has been set but I didnt found yet?) in the original fork, will try adding flags later. Also some features added to my fork Readme-PS.md for ideas memo, testing and lite cmake usage for who want to try.

[TaiXeflar]

Crossmake build test Update:

Recently try to solve building documentation (.tex) files with pandoc(Build docs in a ez way first). This works great to generate basic HTML manual, in the text description and sample code part are readable(finally). I will setting up this part as optional, and add tex compiler check rules by adding new cmake modules (`.cmake`) in project top-dir. Also the original doxygen will try to add into it.

And the features relied on POSIX, there's some ways can try on windows. Like pthreads on win32, build this from source(wget src codes and cmake it) and add to PATH maybe can let tform.exe works..........

[tueda]

vcpkg has the pthreads package, which uses PThreads4W on Windows. So, I guess it is rather straightforward if you use it.