WIP: Build FLTK from source

[davidovski]

Testing to see if its viable to use the system fltk installation rather than pre-compiled ones. Aiming to find a solution for #117

[davidovski]

Thank you @MoAlyousef for your patches!

Currently able to generate, build and run this module, using the generate stage to fetch and compile FLTK-1.4 from source.

However when building as a depedency of another project with go build, go:generate is not called, meaning that fltk is never built, causing the module to not link to FLTK libraries.

I am able to successfully run a project using go-fltk, by manually running go generate or build_fltk.sh within the module directory generated by go (~/go/pkg/mod/...).

Either I am missing something with the way that go generate works, or building fltk via it is not possible in this configuration. Happy to accept any suggestions on how this pre-build stage can be achieved.

[pwiecz]

@davidovski @MoAlyousef I was considering including fltk repository as a submodule instead of fetching the tip of the branch every time.
It seems to give a bit more control, and doesn't require any additional tools besides git to work, afaik.
Do you have any experience with putting submodules into go source repository and can recommend for or against?
I'm also looking for a way to use fltk-config to generate the #cgo directive as well, once the library is compiled, it doesn't work yet, but I still have hope.

[davidovski]

Im not sure what you mean by a submodule. If you mean via git, then I can advise against it, since it seems that when a module is fetched via go get, submodules are not updated/cloned. It also seems that when go get fetches the source for the module to build, it does not keep git respository data, so simply running git submodule update before building isn't sufficient. Thats why in the last commit I switched the generate script to fetch the fltk repository via a tarball instead, though this could probably be replaced with a git clone $fltk_url.

As far as the current state of this PR goes, it seems that all that is required is for go to automatically run generate before building any module, that way, when including go-fltk in a different project, fltk will also be fetched and built in the process. If there was a feature similar to what @MoAlyousef described in #117 within go itself, that would be perfect. I'll look into it more and if not, it might be worth considering bringing it as a proposal upstream to go, if it hasn't already.

[pwiecz]

I wouldn't count on go changing its behaviour, but who knows. :(
It's a bummer that repository metadata is not fetched, when one calls go get, as I was hoping to avoid having to refetch the whole repo, and rebuild tge whole library from scratch everytime user calls go generate (although having an easy way to make a clean rebuild is also nice).
I wantvto look into it dor awhile before committing to a solution.

[pwiecz]

@davidovski , @MoAlyousef I've used your script as a base for implementing similar script in branch: https://github.com/pwiecz/go-fltk/tree/from_source
The script invoked by go generate is here: https://github.com/pwiecz/go-fltk/blob/from_source/fltk-build.sh and the windows version here: https://github.com/pwiecz/go-fltk/blob/from_source/fltk-build.bat
Unfortunately, I don't have MacOS machine to test if it works there. :(

[davidovski]

Looks good, I haven't got a macos machine to test with either, but I see no alarming reason why it shouldn't work. One small thing that you could do to improve the shell script is to use /bin/sh -e, which essentially achieves the same thing as the || exit 1 on each line.

[MoAlyousef]

I can check tomorrow to see if it works on macos (technically it should).

[MoAlyousef]

I tried on macos x86_64, the generated cgo_darwin_amd64.go file is this:

-n //go:build darwin && amd64

package fltk

// #cgo darwin,amd64 CXXFLAGS: -std=c++11
// #cgo darwin,amd64 CPPFLAGS: 
-I${SRCDIR}/include -I${SRCDIR}/include/FL/images -I${SRCDIR}/include/png -I${SRCDIR}/include/zlib -I${SRCDIR}/include/jpeg -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT
-n // #cgo darwin,amd64 LDFLAGS: 
${SRCDIR}/lib/darwin/amd64/libfltk_images.a ${SRCDIR}/lib/darwin/amd64/libfltk_jpeg.a ${SRCDIR}/lib/darwin/amd64/libfltk_png.a ${SRCDIR}/lib/darwin/amd64/libfltk_z.a ${SRCDIR}/lib/darwin/amd64/libfltk_gl.a -framework OpenGL ${SRCDIR}/lib/darwin/amd64/libfltk_forms.a ${SRCDIR}/lib/darwin/amd64/libfltk.a -lm -lpthread -framework Cocoa
import "C"

Notice the -n before the comments. Not sure where that's coming from!

[pwiecz]

@MoAlyousef thanks for teating!
Apparently the MacOS shell does not support -n parameter to the echo command, as it's not rewuired by the POSIX standard.
I'll probably change the uses of echo to printf which seems to provide the required functionalities

[MoAlyousef]

Manually fixing the output (removing the -n) and removing the line break after the LDFLAGS and CPPFLAGS cgo directives causes the build to succeed.