CMake: add 'examples' to build [was: Something in progress? (table examples broken on Linux)]

[Albrecht Schlosser]

[Moved from fltk.general to fltk.coredev]

On 8/13/20 5:41 PM Albrecht Schlosser wrote:
> On 8/13/20 2:49 PM Greg Ercolano wrote:
>
>>     Currently the '(mkdir build; cd build; cmake ..; make )' approach
>>     doesn't provide a way to build all the examples in an automated way.
>
> I *promise* I'll add this feature soon to avoid
> such hacks as mentioned above.

Done as a feature branch in my FLTK fork:
https://github.com/Albrecht-S/fltk/tree/feature-examples
https://github.com/fltk/fltk/compare/master...Albrecht-S:feature-examples

You can clone my fork or add it as a remote to your Git config and pull
my branch 'feature-examples':
https://github.com/Albrecht-S/fltk.git

I did not yet commit/push it to fltk/fltk because there are some details
we need to decide:

Author: Albrecht Schlosser <albrech...@online.de>
Date: Thu Aug 13 20:32:56 2020 +0200

CMake: add examples folder to build (optional)

- Replace misnamed option 'OPTION_BUILD_EXAMPLES' with 'BUILD_DEMOS'.
- Add option 'BUILD_EXAMPLES' to build apps in examples folder


- is 'BUILD_DEMOS' the name we want to use for the "old" test/demo
programs (former 'OPTION_BUILD_EXAMPLES')

I started a discussion but we didn't decide this finally.

- is 'BUILD_EXAMPLES' okay for the example programs (examples folder)?

- what should be the default for 'BUILD_EXAMPLES': ON or OFF?

I chose OFF for backwards compatibility, but I'd vote for ON in the
final commit.

Note that I tried to link all "examples" with the minimal sets of libraries.

Note also that the OpenGL demos had not been included in the provided
examples/Makefile. These demos use libGLEW, hence I added another test
for this library. If OpenGL and/or GLEW is not available, the OpenGL
demos are not built.

Final note: I just switched 'BUILD_EXAMPLES' ON for our Travis-CI builds
to test on all platforms, but this can be switched off later if required.

[Greg Ercolano]

On 2020-08-13 12:03, Albrecht Schlosser wrote:
> 1. is 'BUILD_DEMOS' the name we want to use for the "old" test/demo
> programs (former 'OPTION_BUILD_EXAMPLES')
> 2. is 'BUILD_EXAMPLES' okay for the example programs (examples folder)?
> 3. what should be the default for 'BUILD_EXAMPLES': ON or OFF?

Would it make sense to use:

FLTK_BUILD_TEST
FLTK_BUILD_EXAMPLES

..? It seems to make sense to use the same names as the dirs,
and by using the FLTK_ prefix, there's no collision with other
cmake variables.

And yes, I'd vote for examples to be off by default during library
builds.. at least for now. I'm not sure all examples work on all
platforms, TBH, as they are not as carefully tested across platforms
as the tests, and don't have access to the drivers stuff to avoid
#ifdef <OS> guards.

> Note also that the OpenGL demos had not been included in the provided
> examples/Makefile. These demos use libGLEW, hence I added another test
> for this library. If OpenGL and/or GLEW is not available, the OpenGL
> demos are not built.

Sounds good.

[Albrecht Schlosser]

On 8/13/20 9:19 PM Greg Ercolano wrote:
> On 2020-08-13 12:03, Albrecht Schlosser wrote:
>> 1. is 'BUILD_DEMOS' the name we want to use for the "old" test/demo
>> programs (former 'OPTION_BUILD_EXAMPLES')
>> 2. is 'BUILD_EXAMPLES' okay for the example programs (examples folder)?
>> 3. what should be the default for 'BUILD_EXAMPLES': ON or OFF?
>
> Would it make sense to use:
>
> FLTK_BUILD_TEST
> FLTK_BUILD_EXAMPLES
>
> ..? It seems to make sense to use the same names as the dirs,
> and by using the FLTK_ prefix, there's no collision with other
> cmake variables.

I don't think we need the 'FLTK_' prefix to avoid collisons because most
of the relevant CMake variables have their own 'CMAKE_' prefix, but I'm
open for proposals.

And yes, using the dir name makes sense, but I'd also suggest to be
consistent with singular and plural (preferring plural) which
contradicts the strict "directory name", so I'd suggest

either

FLTK_BUILD_TESTS
FLTK_BUILD_EXAMPLES

or

BUILD_TESTS
BUILD_EXAMPLES

I'd prefer the shorter versions in case someone needs to type the names
on the command line, but I'd be fine with the FLTK_ prefix as well.

> And yes, I'd vote for examples to be off by default during library
> builds.. at least for now. I'm not sure all examples work on all
> platforms, TBH, as they are not as carefully tested across platforms
> as the tests, and don't have access to the drivers stuff to avoid
> #ifdef <OS> guards.

Travis-CI built all the examples fine on both Linux and Mac, but I
didn't see the OpenGL examples, very likely because libGLEW was not
found on the Travis-CI build system.

>> Note also that the OpenGL demos had not been included in the provided
>> examples/Makefile. These demos use libGLEW, hence I added another test
>> for this library. If OpenGL and/or GLEW is not available, the OpenGL
>> demos are not built.

Can anybody with macOS please help with `libGLEW'?

I need to know where libGLEW* can be found on macOS, if available (full
path) and how to install it if it's not available. Note that we can
install it on the Travis-CI build system if we know how to do it, for
reference see this part of .travis.yml (with line numbers):

37 before_script:
38 - |
39 if [ $TRAVIS_OS_NAME == linux ]; then
40 sudo apt-get update -q
41 sudo apt-get install -y libxinerama-dev libxcursor-dev
libasound2-dev libglew-dev
42 sudo apt-get install -y doxygen
43 elif [ $TRAVIS_OS_NAME == osx ]; then
44 brew install ccache # need to install on OSX
45 export PATH="/usr/local/opt/ccache/libexec:$PATH"
46 brew install doxygen
47 fi


I just added 'libglew-dev' for Linux builds and looking forward to
travis-ci build results...

Great, it worked (on Linux):

Scanning dependencies of target OpenGL3test

[ 84%] Building CXX object
examples/CMakeFiles/OpenGL3test.dir/OpenGL3test.cxx.o

[ 84%] Linking CXX executable ../bin/examples/OpenGL3test

[ 84%] Built target OpenGL3test

Scanning dependencies of target OpenGL3-glut-test

[ 85%] Building CXX object
examples/CMakeFiles/OpenGL3-glut-test.dir/OpenGL3-glut-test.cxx.o

[ 85%] Linking CXX executable ../bin/examples/OpenGL3-glut-test

[ 85%] Built target OpenGL3-glut-test


Who can help with macOS (libGLEW)?

[gga]

On 13/8/20 17:39, Albrecht Schlosser wrote:
>
> Who can help with macOS (libGLEW)?
>

To install it, do:

brew install glew

On my machine, it places it a symlink:

/usr/local/lib/libGLEW.dylib / libGLEW.a

--
Gonzalo Garramuño

[Albrecht Schlosser]

On 8/13/20 11:01 PM gga wrote:
>
> On 13/8/20 17:39, Albrecht Schlosser wrote:
>>
>> Who can help with macOS (libGLEW)?
>>
> To install it, do:
>
> brew install glew
>
> On my machine, it places it a symlink:
>
> /usr/local/lib/libGLEW.dylib / libGLEW.a

Thanks, tried it and worked:

CMake test:

-- LIB_GLEW = '/usr/local/lib/libGLEW.dylib'

Build:
...

Scanning dependencies of target OpenGL3test

[ 91%] Building CXX object
examples/CMakeFiles/OpenGL3test.dir/OpenGL3test.cxx.o
[ 91%] Linking CXX executable
../bin/examples/OpenGL3test.app/Contents/MacOS/OpenGL3test
[ 91%] Built target OpenGL3test

Scanning dependencies of target OpenGL3-glut-test

[ 92%] Building CXX object
examples/CMakeFiles/OpenGL3-glut-test.dir/OpenGL3-glut-test.cxx.o
[ 92%] Linking CXX executable
../bin/examples/OpenGL3-glut-test.app/Contents/MacOS/OpenGL3-glut-test
[ 92%] Built target OpenGL3-glut-test
...


Now we need someone to test on macOS... TIA.

[Greg Ercolano]

On 2020-08-13 13:39, Albrecht Schlosser wrote:
> I need to know where libGLEW* can be found on macOS, if available (full
> path) and how to install it if it's not available

There doesn't seem to be anything called 'glew' on my 10.10.x system.

I'll try installing brew, and then brew installing glew, and see
what paths it uses by default.

[Ian MacArthur]

Or pull the sources from github?

https://github.com/nigels-com/glew

I have no idea if brew installs it to the same place as the source distro...

[Ian MacArthur]

On 13 Aug 2020, at 21:39, Albrecht Schlosser wrote:
>
> And yes, using the dir name makes sense, but I'd also suggest to be consistent with singular and plural (preferring plural) which contradicts the strict "directory name", so I'd suggest
>
> either
>
> FLTK_BUILD_TESTS
> FLTK_BUILD_EXAMPLES
>
> or
>
> BUILD_TESTS
> BUILD_EXAMPLES
>
> I'd prefer the shorter versions in case someone needs to type the names on the command line, but I'd be fine with the FLTK_ prefix as well.

I’d prefer the longer version though - it’s not a thing that folks would have to type *often*, and as Duncan points out it potentially makes the fltk cmake files play nicer if merged with other libs, so...

[Ian MacArthur]

So it looks like the source build installs to /usr/local/... so that would be consistent with what Gonzalo suggests that brew does anyway.


FWIW, I used to have glew for a project and never installed it at all - like fltk it worked perfectly well from the build dir.

That would not help with cmake though!

[Greg Ercolano]

On 2020-08-13 13:39, Albrecht Schlosser wrote:

> And yes, using the dir name makes sense, but I'd also suggest to be
> consistent with singular and plural (preferring plural)

-1 from me, main reason being why be different from our existing naming?

Also, as I watch 'brew install glew' (been running for 1/2 hour now, still
working on it), I see:

==> Installing glew dependency: openssl@1.1
==> perl ./Configure --prefix=/usr/local/Cellar/openssl@1.1/1.1.1g --openssldir=/usr/local/etc/openssl@1.1 no-
==> make
==> make test <-- singular

..so singular is not without precedent in other packages, even though
I'm sure there is more than one actual test.

> FLTK_BUILD_TESTS
> FLTK_BUILD_EXAMPLES
>
> or
>
> BUILD_TESTS
> BUILD_EXAMPLES

+1 from me for FLTK_ prefixes, but not strongly.

> Can anybody with macOS please help with `libGLEW'?

OK, brew just got finished on my 10.10.3 machine.

Paths to the includes:

[erco@heron] 14 : ls -la /usr/local/include/GL/*
-rw-r--r-- 1 erco admin 1186601 Jul 31 2017 /usr/local/include/GL/glew.h
-rw-r--r-- 1 erco admin 73435 Jul 31 2017 /usr/local/include/GL/glxew.h
-rw-r--r-- 1 erco admin 63314 Jul 31 2017 /usr/local/include/GL/wglew.h

Paths to this libs:

[erco@heron] 13 : ls -la /usr/local/lib/*GLEW*
lrwxr-xr-x 1 erco admin 46 Aug 13 14:59 /usr/local/lib/libGLEW.2.1.0.dylib -> ../Cellar/glew/2.1.0_1/lib/libGLEW.2.1.0.dylib
lrwxr-xr-x 1 erco admin 44 Aug 13 14:59 /usr/local/lib/libGLEW.2.1.dylib -> ../Cellar/glew/2.1.0_1/lib/libGLEW.2.1.dylib
lrwxr-xr-x 1 erco admin 36 Aug 13 14:59 /usr/local/lib/libGLEW.a -> ../Cellar/glew/2.1.0_1/lib/libGLEW.a
lrwxr-xr-x 1 erco admin 40 Aug 13 14:59 /usr/local/lib/libGLEW.dylib -> ../Cellar/glew/2.1.0_1/lib/libGLEW.dylib

I think "Cellar" is brew's internal naming.

I think in the case of brew, 'pkg-config' might be the better way to tell
the fltk build system where to find glew:

$ pkg-config glew --cflags
-I/usr/local/Cellar/glew/2.1.0_1/include

$ pkg-config glew --libs
-L/usr/local/Cellar/glew/2.1.0_1/lib -lGLEW

[Greg Ercolano]

On 2020-08-13 15:02, Ian MacArthur wrote:
> Or pull the sources from github?
> https://github.com/nigels-com/glew
> I have no idea if brew installs it to the same place as the source distro...

I'll try that too, just for completeness, and report back.

Most things like this on Apple install to /usr/local/
Even though Apple uses nutty names for things, most developers still look
at OSX as unix, and follow unix's /usr/local naming convention, me thinks.

There are some odd exceptions, such as those that like /opt, which I've
always hated; creating stuff off the root directory is very bad IMHO.
And these days impossible on OS's like Catalina, where even root can't
create directories in / in multiuser mode; the OS directories are read only,
and can only be written to in recovery mode.

[Greg Ercolano]

> On 13 Aug 2020, at 23:02, Ian MacArthur wrote:
>> Or pull the sources from github?
>> https://github.com/nigels-com/glew
>> I have no idea if brew installs it to the same place as the source distro...
>
> So it looks like the source build installs to /usr/local/... so that would
> be consistent with what Gonzalo suggests that brew does anyway.

Ah, looks like you did it already, so I won't bother with the git-hub install.

[Manolo]

On Thursday, August 13, 2020 at 10:39:34 PM UTC+2 Albrecht Schlosser wrote:

Can anybody with macOS please help with `libGLEW'?

Files OpenGL3test.cxx and OpenGL3-glut-test.cxx in directory examples are there to show

how to use OpenGL version 3 (which is a deep change relative to OpenGL2) with FLTK.

The FLTK/OpenGL3 was conceived (by me) to require libGLEW under the X11 and Windows platforms,

but no additional library is necessary under macOS. That's also visible in the source code:

#ifndef __APPLE__
      GLenum err = glewInit(); // defines pters to functions of OpenGL V 1.2 and above
      if (err) Fl::warning("glewInit() failed returning %u", err);
      else add_output("Using GLEW %s\n", glewGetString(GLEW_VERSION));
#endif

Thus, it's not necessary (nor meaningful) to install libGLEW on macOS to build all examples.

 

[Manolo]

A word is missing in the message above. Please, read instead:

The FLTK/OpenGL3 interface was conceived…

[Albrecht Schlosser]

On 8/14/20 12:12 AM Greg Ercolano wrote:
> On 2020-08-13 13:39, Albrecht Schlosser wrote:
>> And yes, using the dir name makes sense, but I'd also suggest to be
>> consistent with singular and plural (preferring plural)
>
> -1 from me, main reason being why be different from our existing naming?
>

> +1 from me for FLTK_ prefixes, but not strongly.

OK, I believe the majority wants

- FLTK_BUILD_TEST
- FLTK_BUILD_EXAMPLES

or at least this is the best compromise from what I read so far.

I changed my branch to use this. Note that I squashed the commits and
force-pushed the branch, hence you may need to update your working copy.

Please pull from my fork Albrecht-S/fltk (branch: feature-examples) and
test. TIA.

>> Can anybody with macOS please help with `libGLEW'?
>
> OK, brew just got finished on my 10.10.3 machine.
>
> Paths to the includes:
>
> [erco@heron] 14 : ls -la /usr/local/include/GL/*
> -rw-r--r-- 1 erco admin 1186601 Jul 31 2017 /usr/local/include/GL/glew.h
> -rw-r--r-- 1 erco admin 73435 Jul 31 2017 /usr/local/include/GL/glxew.h
> -rw-r--r-- 1 erco admin 63314 Jul 31 2017 /usr/local/include/GL/wglew.h
>
> Paths to this libs:
>
> [erco@heron] 13 : ls -la /usr/local/lib/*GLEW*
> lrwxr-xr-x 1 erco admin 46 Aug 13 14:59 /usr/local/lib/libGLEW.2.1.0.dylib -> ../Cellar/glew/2.1.0_1/lib/libGLEW.2.1.0.dylib
> lrwxr-xr-x 1 erco admin 44 Aug 13 14:59 /usr/local/lib/libGLEW.2.1.dylib -> ../Cellar/glew/2.1.0_1/lib/libGLEW.2.1.dylib
> lrwxr-xr-x 1 erco admin 36 Aug 13 14:59 /usr/local/lib/libGLEW.a -> ../Cellar/glew/2.1.0_1/lib/libGLEW.a
> lrwxr-xr-x 1 erco admin 40 Aug 13 14:59 /usr/local/lib/libGLEW.dylib -> ../Cellar/glew/2.1.0_1/lib/libGLEW.dylib
>
> I think "Cellar" is brew's internal naming.

Thanks to you and all who helped with other information.

As I wrote earlier 'brew install glew' as suggested by Gonzalo did the
job for our Travis-CI build, hence I could verify that it works (in this
particular environment: a docker container).

> I think in the case of brew, 'pkg-config' might be the better way to tell
> the fltk build system where to find glew:
>
> $ pkg-config glew --cflags
> -I/usr/local/Cellar/glew/2.1.0_1/include
>
> $ pkg-config glew --libs
> -L/usr/local/Cellar/glew/2.1.0_1/lib -lGLEW

Thanks for this as well. I remember that we tried to avoid pkg-config in
earlier versions of our builds but we really needed it recently to
replace freetype-config and we're using it for Cairo as well, so I think
we could use it. But for now I'd stick with CMake's built-in functions
(find_library and/or find_package) unless we /need/ to switch to
pkg-config for some yet unknown reason.

[Albrecht Schlosser]

On 8/14/20 8:51 AM Manolo wrote:
>
> Files OpenGL3test.cxx and OpenGL3-glut-test.cxx in directory examples
> are there to show how to use OpenGL version 3 (which is a deep change
> relative to OpenGL2) with FLTK.
> The FLTK/OpenGL3 was conceived (by me) to require libGLEW under the X11
> and Windows platforms,
> but no additional library is necessary under macOS. That's also visible
> in the source code:
> #ifndef __APPLE__
>       GLenum err = glewInit(); // defines pters to functions of OpenGL
> V 1.2 and above
>       if (err) Fl::warning("glewInit() failed returning %u", err);
>       else add_output("Using GLEW %s\n", glewGetString(GLEW_VERSION));
> #endif
>
> Thus, it's not necessary (nor meaningful) to install libGLEW on macOS to
> build all examples.

Oh, thanks for this important info.

I removed the libGLEW check on macOS and reverted the Travis-CI install
of libGLEW as well so this doesn't confuse people.

Travis-CI reports success and builds the OpenGL3 examples on macOS.
https://travis-ci.com/github/Albrecht-S/fltk/jobs/372009381

You can pull from my branch to test:
https://github.com/Albrecht-S/fltk/tree/feature-examples

All test results are welcome, particularly on macOS.

There's one more question though:

I put the binaries in bin/examples as opposed to bin/ for all the other
test programs and fluid.

Should we put all (test + examples) programs together in the bin/
directory or leave it as-is (examples in bin/examples)?

Separating the programs has the advantage of a little better structure,
but I can also imagine having all test + examples programs in one directory.

I vote +/- 0

Another question regarding macOS only: I'm not sure where the wrapper
scripts get installed (now). Are they installed in bin/examples or are
they all installed in bin/ ? Can anybody please test and tell me?

[Greg Ercolano]

On 2020-08-14 01:39, Albrecht Schlosser wrote:
> On 8/14/20 8:51 AM Manolo wrote:
> There's one more question though:
>
> I put the binaries in bin/examples as opposed to bin/ for all the other
> test programs and fluid.
>
> Should we put all (test + examples) programs together in the bin/
> directory or leave it as-is (examples in bin/examples)?
>
> Separating the programs has the advantage of a little better structure,
> but I can also imagine having all test + examples programs in one directory.
>
> I vote +/- 0

I'm about to crash for the nite, but I'd suggest if possible
the simplest, most sensical structure to me would be to mirror
the fltk directory structure under <build> for the binaries, e.g.

fltk/<build>/test/ <-- test executables
fltk/<build>/examples/ <-- examples executables

..just so that they're separate and not mixed, otherwise people
wouldn't know which execs are test and which are examples, and
couldn't easily rm just the examples, etc.

This way too we wouldn't have to worry about name overlaps.

So e.g.

mkdir build
cd build
cmake ..

make examples
./examples/table-simple -scheme gtk+

But if things really need to be in <build>/bin for some reason,
then I'd next hope for:

<build>/bin/test/ <-- test executables
<build>/bin/examples/ <-- examples executables

..and I guess my last choice would be:

<build>/bin/ <-- test executables
<build>/bin/examples/ <-- examples executables

..and I think I'd be -1 for putting them all together.
But I'd like to hear from others.

[Albrecht Schlosser]

On Am 8/14/20 10:53 AM schrieb Greg Ercolano wrote:
> On 2020-08-14 01:39, Albrecht Schlosser wrote:
>> On 8/14/20 8:51 AM Manolo wrote:
>> There's one more question though:
>>
>> I put the binaries in bin/examples as opposed to bin/ for all the other
>> test programs and fluid.
>>
>> Should we put all (test + examples) programs together in the bin/
>> directory or leave it as-is (examples in bin/examples)?
>>
>> Separating the programs has the advantage of a little better structure,
>> but I can also imagine having all test + examples programs in one directory.
>>
>> I vote +/- 0
>
> I'm about to crash for the nite, but I'd suggest if possible
> the simplest, most sensical structure to me would be to mirror
> the fltk directory structure under <build> for the binaries, e.g.
>
> fltk/<build>/test/ <-- test executables
> fltk/<build>/examples/ <-- examples executables
>
> ..just so that they're separate and not mixed, otherwise people
> wouldn't know which execs are test and which are examples, and
> couldn't easily rm just the examples, etc.
>
> This way too we wouldn't have to worry about name overlaps.

I'd rule out this concept because CMake uses these dirs for their own
files created by the CMake configure + build phase. Please take a look
at these dirs and you'll see. This has been one of the reasons to put
them in an extra bin/ directory (originally: bin/examples/ as you
certainly know).

If you just wanna remove the created executables it's far easier to `rm
-rf bin/` which is guaranteed to hold only executables (and maybe macOS
wrapper scripts). BTW, this is similar to the lib/ directory that holds
all created libs (not the src/ dir and the cairo/ dir etc.).

> But if things really need to be in <build>/bin for some reason,
> then I'd next hope for:
>
> <build>/bin/test/ <-- test executables
> <build>/bin/examples/ <-- examples executables

I wanted to get rid of the subdirs and put the test/* executables in the
bin/ dir where previously only fluid was generated to be able to use a
well-known structure for test/demo so we could run fluid and all the
test programs from the same directory w/o adding lots of directory
handling stuff (in test/demo.cxx).

Therefore I'd *really* like to keep the created fluid and test/*.cxx
executables all together in one directory. Otherwise we'd need to
revisit test/demo.cxx to sort that out again.

Please consider that test/demo.cxx must be able to execute the test
programs from the fltk/test folder for autoconf/make builds and from
build/bin/something folder(s) for CMake builds and for all different
variants of Xcode, VS, make, ninja, ...

It was hard work to get this going, I wouldn't like to change this again.

> ..and I guess my last choice would be:
>
> <build>/bin/ <-- test executables
> <build>/bin/examples/ <-- examples executables

This is as it is done now in my test branch. It works and it's the
easiest way to go.

I think this would be my choice: +1

> ..and I think I'd be -1 for putting them all together.

I'm fine with that (not putting them all together), although I
anticipate that the macOS wrappers would need a little more work if we
have '<build>/bin/' and '<build>/bin/examples/'.

> But I'd like to hear from others.

So do I.

Thanks for your comments.

[Manolo]

On Friday, August 14, 2020 at 10:39:46 AM UTC+2 Albrecht Schlosser wrote:

You can pull from my branch to test:
https://github.com/Albrecht-S/fltk/tree/feature-examples

I did that

All test results are welcome, particularly on macOS.

Building with CMake on macOS runs OK here.

There's one more question though:

I put the binaries in bin/examples as opposed to bin/ for all the other
test programs and fluid.

Should we put all (test + examples) programs together in the bin/
directory or leave it as-is (examples in bin/examples)?

Separating the programs has the advantage of a little better structure,
but I can also imagine having all test + examples programs in one directory.

I vote +/- 0

I would support to maintain tests and examples in distinct folders.

I'm lost with option names. I use cmake-gui which lists only one option

called OPTION_BUILD_EXAMPLES that's ON by default and that builds only

sources from test, not those from examples.

Another question regarding macOS only: I'm not sure where the wrapper
scripts get installed (now). Are they installed in bin/examples or are
they all installed in bin/ ? Can anybody please test and tell me?

There are no wrapper scripts anymore (which is fine for me).

[Greg Ercolano]

On 2020-08-14 08:12, Manolo wrote:
> Another question regarding macOS only: I'm not sure where the wrapper
> scripts get installed (now). Are they installed in bin/examples or are
> they all installed in bin/ ? Can anybody please test and tell me?
>
> There are no wrapper scripts anymore (which is fine for me).

Hmm, are you sure you did a 'git checkout feature-examples' from his branch first?
When I do that I get wrappers in the bin directory. (Will follow up with details separately)

You might have just built his fork's master branch.

[Greg Ercolano]

On 2020-08-14 04:00, Albrecht Schlosser wrote:

>> fltk/<build>/test/ <-- test executables
>> fltk/<build>/examples/ <-- examples executables
>>

> I'd rule out this concept because CMake uses these dirs for their own
> files created by the CMake configure + build phase. Please take a look
> at these dirs and you'll see. This has been one of the reasons to put
> them in an extra bin/ directory (originally: bin/examples/ as you
> certainly know).

That's too bad, as I think the contents of those dirs will
confuse folks used to FLTK's old autoconf results and following
old docs.

So just curious: couldn't we target those dirs for the binaries
anyway? Or would that complicate the 'make clean' target?

Just checking to make sure there isn't a way out, as it just
seems like the obvious place for stuff to go.

My thinking of the optimal layout would be:

<build>/bin <-- fluid (wrapper on OSX) and fltk-config would go here
<build>/examples <-- example execs (mixed with some cmake cruft might be OK)
<build>/test <-- test execs (mixed with some cmake cruft might be OK)

But if there might be crosstalk between cmake's needs
and our stuff, perhaps that's bad.

>> But if things really need to be in <build>/bin for some reason,
>> then I'd next hope for:
>>
>> <build>/bin/test/ <-- test executables
>> <build>/bin/examples/ <-- examples executables
>
> I wanted to get rid of the subdirs and put the test/* executables in the
> bin/ dir where previously only fluid was generated to be able to use a
> well-known structure for test/demo so we could run fluid and all the
> test programs from the same directory w/o adding lots of directory
> handling stuff (in test/demo.cxx).

I'm sure you've researched carefully, but I think if we don't
do the above, we'll have to be more specific in our docs,
as the autoconf/make vs cmake/make results will differ as
to where to find stuff. Old docs will be wrong.

> Therefore I'd *really* like to keep the created fluid and test/*.cxx
> executables all together in one directory. Otherwise we'd need to
> revisit test/demo.cxx to sort that out again.
>
> Please consider that test/demo.cxx must be able to execute the test
> programs from the fltk/test folder for autoconf/make builds and from
> build/bin/something folder(s) for CMake builds and for all different
> variants of Xcode, VS, make, ninja, ...
>
> It was hard work to get this going, I wouldn't like to change this again.
>
>> ..and I guess my last choice would be:
>>
>> <build>/bin/ <-- test executables
>> <build>/bin/examples/ <-- examples executables
>
> This is as it is done now in my test branch. It works and it's the
> easiest way to go.

OK, but if we go this route, I'd /highly/ recommend a small banner
at the end of the build process saying where stuff is:

--- COMPLETED
To build examples, run 'make examples'.
LIBS: ./lib
BINS: ./bin (fltk-config, fluid..)
TEST PROGRAMS: ./bin (e.g. demo, hello, etc)
EXAMPLE PROGRAMS: ./bin (e.g. tree-simple, etc)

>> You can pull from my branch to test:
>> https://github.com/Albrecht-S/fltk/tree/feature-examples

>> [..]

>> Another question regarding macOS only: I'm not sure where the wrapper
>> scripts get installed (now). Are they installed in bin/examples or are
>> they all installed in bin/ ? Can anybody please test and tell me?

I did the following on 10.10.3:

git clone g...@github.com:Albrecht-S/fltk.git fltk-albrecht-fork
cd fltk-albrecht-fork
git checkout feature-examples
mkdir build
cd build
cmake -D OPTION_USE_SYSTEM_LIBPNG=off -D OPTION_USE_SYSTEM_ZLIB=off ..
make -j 4

..and it looks like both wrappers and .apps are in the ./bin directory.

Question: I'm not sure I know how to build the 'examples' -- what should
I use to test that? I tried the things that seemed obvious to me:

$ pwd
/net/tmp/fltk-albrecht-fork/build

$ make examples
make: *** No rule to make target `examples'. Stop. <-- nope

$ cd ../examples; make <-- nope
make: ../fltk-config: Command not found
make: ../fltk-config: Command not found
*** Compile browser-simple.cxx...
make: I..: No such file or directory
make: ../fltk-config: Command not found
make: ../fltk-config: Command not found
make: ../fltk-config: Command not found
*** Linking browser-simple...
make: browser-simple.o: No such file or directory
make: *** [browser-simple] Error 1

I think you mentioned the examples were enabled by default in this branch,
but I couldn't find e.g. 'tree-simple' in the build dir:

$ pwd
/net/tmp/fltk-albrecht-fork/build

$ find . | grep tree-simple

$

..so I assumed I need to run a follow up make command to build it, but maybe
that's not ready yet.

[Manolo]

Correct.

With the  feature-examples branch, everything builds well under macOS with CMake, and wrappers

are where there should be, next to each application bundle. Examples also build well

and get their wrapper.

[Greg Ercolano]

On 2020-08-14 10:29, Greg Ercolano wrote:
> My thinking of the optimal layout would be:
>
> <build>/bin <-- fluid (wrapper on OSX) and fltk-config would go here
> <build>/examples <-- example execs (mixed with some cmake cruft might be OK)
> <build>/test <-- test execs (mixed with some cmake cruft might be OK)

Also: I think keeping fltk-config and fluid in a separate bin dir would help
motivate developers to add <build>/bin to their own Makefile PATH's so as to
reach those tools, and those tools alone, without accidentally picking up all
the other test + example executables in their build path.

So even if we have to go with putting test + examples in the same dir, perhaps
it would be useful to be kept separate from the fltk-config + fluid bin dir.

[Manolo]

Under macOS and after CMake build, test programs help_dialog, browser and colbrowser don't find their

respective support file which sits in the data folder.

[Greg Ercolano]

On 2020-08-14 11:18, Manolo wrote:
> Under macOS and after CMake build, test programs help_dialog, browser and colbrowser don't find their
> respective support file which sits in the data folder.

Confirmed; when I run the wrapper:

$ bin/help_dialog

I get the error dialog:

Error
Unable to follow the link "bin/help_dialog.app/Contents/MacOS/../Resources/help_dialog.html" - No such file or directory.

There doesn't appear to be a Resources directory under help_dialog.app/Contents:

$ ls -la bin/help_dialog.app/Contents/
total 8
drwxr-xr-x 4 root wheel 136 Aug 14 09:53 .
drwxr-xr-x 3 root wheel 102 Aug 14 09:53 ..
-rw-rw-r-- 1 root wheel 995 Aug 14 09:53 Info.plist
drwxr-xr-x 3 root wheel 102 Aug 14 09:53 MacOS

HTH

[Albrecht Schlosser]

Well, this is still some macOS specific code that assumes that the
support file (in this case 'help_dialog.html') is in the bundle's
Resources folder, but we don't do this anymore since the redesign of the
test/demo app and introduction of the data/ directory.

I'm not sure what to suggest to fix this. For now there are two ways
that /should/ work though:

(1) run the demo app and start the help_dialog app by using the menu.
This was the main reason to rewrite the test/demo app.

(2) run the help_dialog app (bundle or wrapper) with an explicit path to
the html file, something like `./help_dialog ../data/help_dialog.html`.

Both ways *should* work, and both are using an explicit argument with a
full or relative path respectively.

Note: running the application `help_dialog` in the build folder w/o an
explicit argument doesn't work on all platforms. Putting the html file
into the bundle and using the macOS specific "hack" to open the file in
the bundle seemed to work but without the images this would also be only
an incomplete solution.

I don't have a solution right now. My priority was to make the test/demo
program work with all programs executed via the demo menu. I'm pretty
sure this works now.

Although we could fix the issue on macOS by packaging all support files
in their respective bundles this wouldn't solve the issue for any other
platform, i.e. you can't run build/bin/colbrowser under Linux and expect
it to find the rgb.txt file in the data/ directory. It would be less
complicated if the Visual Studio and Xcode build didn't use their own
subdirs per build type, i.e. build/bin/Debug/colbrowser.exe (VS) or
build/bin/Debug/colbrowser.app (macOS bundle).

[Albrecht Schlosser]

On 8/14/20 7:29 PM Greg Ercolano wrote:
> On 2020-08-14 04:00, Albrecht Schlosser wrote:
>
>>> fltk/<build>/test/ <-- test executables
>>> fltk/<build>/examples/ <-- examples executables
>>>
>> I'd rule out this concept because CMake uses these dirs for their own
>> files created by the CMake configure + build phase. Please take a look
>> at these dirs and you'll see. This has been one of the reasons to put
>> them in an extra bin/ directory (originally: bin/examples/ as you
>> certainly know).
>
> That's too bad, as I think the contents of those dirs will
> confuse folks used to FLTK's old autoconf results and following
> old docs.

Please, don't "think backwards". ;-)

(no offense intended, please read further)

Some folks might have got used to the old autoconf build and its
peculiarities, but think about it: where did you find the Windows DLL's
and the shared libs and static libs? Was this really (well) documented?
I don't think so (too late to check).

Now, "thinking forwards" ;-)

With FLTK 1.4 we decided to use CMake as our primary build system and we
should do it better than with the old autoconf system. If we need to
document where to find the test and examples executables, then so be it.
And yes, I think we should.

In other (autoconf based) build systems it is usual to build executables
in a `bin` directory and we do already build our libs in the `lib`
directory.

The new strategy is to create build (output) files in exactly two
directories (maybe with subdirs):

lib - all libs, static and dynamic

bin - all executable files, particularly fluid and fltk-config, but also
all test executables (only fluid and fltk-config will be "installed")

bin/examples - all example files (never "installed")

Basically you only need to remember 'bin' and 'lib'.

The next point is: where are these files installed (with `make install`)?

bin - executable files (fluid, fltk-config)

lib - all libs (static and dynamic)

So, our current build directories are the same as the future *install*
directories, and all created files are contained in these two
directories. Isn't this better and easier to remember than the old
autoconf mess?

Et ceterum censeo: autoconf delendam esse. ;-)

https://translate.google.com/#view=home&op=translate&sl=auto&tl=en&text=Et%20ceterum%20censeo%3A%20autoconf%20delendam%20esse

> So just curious: couldn't we target those dirs for the binaries
> anyway? Or would that complicate the 'make clean' target?

There's no problem with the `make clean` target: no matter where we
create the files, CMake "knows" this and can do it.

But for humans it's IMHO better to have the build dirs (bin and lib)
separated from the directories with the CMake files which are irrelevant
for human users. Users can easily execute:

$ rm -rf bin/ lib/

and run `make` again to recreate all executables and libs (note: this
doesn't compile everything, you'd still have to use `make clean` to
re*compile* the entire build).

I'd really prefer to separate the build (output) dirs from the CMake
work dirs to *avoid* confusion.

> Just checking to make sure there isn't a way out, as it just
> seems like the obvious place for stuff to go.
>
> My thinking of the optimal layout would be:
>
> <build>/bin <-- fluid (wrapper on OSX) and fltk-config would go here
> <build>/examples <-- example execs (mixed with some cmake cruft might be OK)
> <build>/test <-- test execs (mixed with some cmake cruft might be OK)
>
> But if there might be crosstalk between cmake's needs
> and our stuff, perhaps that's bad.

Yes, IMHO this is bad, because (a) "mixed with some cmake cruft" is bad
for users, and (b) because build systems like Visual Studio and Xcode
add their own stuff as well.

>>> But if things really need to be in <build>/bin for some reason,
>>> then I'd next hope for:
>>>
>>> <build>/bin/test/ <-- test executables
>>> <build>/bin/examples/ <-- examples executables

If this is so important for you, then I can try to do it. It's only one
instruction in CMake to direct all test/* executables to the subdir.
Sounds really easy...

BUT: this needs more work to make test/demo.cxx work with all the test
programs and their support files. I put a *lot* of work in the current
status (which is obviously not yet complete) and I'd like to avoid this
extra work. IMHO there are really more important things than this
subdirectory stuff.

Anyway, if it's important and more than one person ;-) wants it, I can
try it...

>> I wanted to get rid of the subdirs and put the test/* executables in the
>> bin/ dir where previously only fluid was generated to be able to use a
>> well-known structure for test/demo so we could run fluid and all the
>> test programs from the same directory w/o adding lots of directory
>> handling stuff (in test/demo.cxx).
>
> I'm sure you've researched carefully, but I think if we don't
> do the above, we'll have to be more specific in our docs,
> as the autoconf/make vs cmake/make results will differ as
> to where to find stuff. Old docs will be wrong.

Please tell me where it's *documented* where all the executables and
libs (and Windows DLL's are created) so we can fix it.

>> Therefore I'd *really* like to keep the created fluid and test/*.cxx
>> executables all together in one directory. Otherwise we'd need to
>> revisit test/demo.cxx to sort that out again.
>>
>> Please consider that test/demo.cxx must be able to execute the test
>> programs from the fltk/test folder for autoconf/make builds and from
>> build/bin/something folder(s) for CMake builds and for all different
>> variants of Xcode, VS, make, ninja, ...
>>
>> It was hard work to get this going, I wouldn't like to change this again.
>>
>>> ..and I guess my last choice would be:
>>>
>>> <build>/bin/ <-- test executables
>>> <build>/bin/examples/ <-- examples executables
>>
>> This is as it is done now in my test branch. It works and it's the
>> easiest way to go.
>
> OK, but if we go this route, I'd /highly/ recommend a small banner
> at the end of the build process saying where stuff is:
>
> --- COMPLETED
> To build examples, run 'make examples'.
> LIBS: ./lib
> BINS: ./bin (fltk-config, fluid..)
> TEST PROGRAMS: ./bin (e.g. demo, hello, etc)
> EXAMPLE PROGRAMS: ./bin (e.g. tree-simple, etc)

We can *maybe* do something like this after the CMake configure/generate
process, similar to what `./configure` does, but probably not after the
build (`make`) process.

>>> You can pull from my branch to test:
>>> https://github.com/Albrecht-S/fltk/tree/feature-examples
>>> [..]
>>> Another question regarding macOS only: I'm not sure where the wrapper
>>> scripts get installed (now). Are they installed in bin/examples or are
>>> they all installed in bin/ ? Can anybody please test and tell me?
>
> I did the following on 10.10.3:
>
> git clone g...@github.com:Albrecht-S/fltk.git fltk-albrecht-fork
> cd fltk-albrecht-fork
> git checkout feature-examples
> mkdir build
> cd build
> cmake -D OPTION_USE_SYSTEM_LIBPNG=off -D OPTION_USE_SYSTEM_ZLIB=off ..
> make -j 4
>
> ..and it looks like both wrappers and .apps are in the ./bin directory.

Note: the interesting question is where the wrappers for the *examples*
apps are (see below for how to enable these).

> Question: I'm not sure I know how to build the 'examples' -- what should
> I use to test that? I tried the things that seemed obvious to me:
>
> $ pwd
> /net/tmp/fltk-albrecht-fork/build
>
> $ make examples
> make: *** No rule to make target `examples'. Stop. <-- nope
>
> $ cd ../examples; make <-- nope
> make: ../fltk-config: Command not found
> make: ../fltk-config: Command not found
> *** Compile browser-simple.cxx...
> make: I..: No such file or directory
> make: ../fltk-config: Command not found
> make: ../fltk-config: Command not found
> make: ../fltk-config: Command not found
> *** Linking browser-simple...
> make: browser-simple.o: No such file or directory
> make: *** [browser-simple] Error 1
>
> I think you mentioned the examples were enabled by default in this branch,
> but I couldn't find e.g. 'tree-simple' in the build dir:
>

> ..so I assumed I need to run a follow up make command to build it, but maybe
> that's not ready yet.

Sorry for the confusion. Yes, I wrote that I set the default for the
examples to "ON" but I later decided to turn it OFF again since it was
no longer needed for the Travis-CI build (it's enabled in the build
process).

The only thing you need to do is to enable the CMake option
"FLTK_BUILD_EXAMPLES", either with the CMake GUI or the commandline flag
`-D FLTK_BUILD_EXAMPLES=ON`. If you like the commandline, just run cmake
again with this flag and it ought to work (it overwrites the current
status).

If you use `cmake-gui` however, you see all possible options.

I also added this already to README.CMake.txt in my branch, BTW.

Then run `make` again and the additional examples should be built.

[Greg Ercolano]

>> Error
>> Unable to follow the link "bin/help_dialog.app/Contents/MacOS/../Resources/help_dialog.html" - No such file or directory.
>>
>> There doesn't appear to be a Resources directory under help_dialog.app/Contents:
>>
>> $ ls -la bin/help_dialog.app/Contents/
>> total 8
>> drwxr-xr-x 4 root wheel 136 Aug 14 09:53 .
>> drwxr-xr-x 3 root wheel 102 Aug 14 09:53 ..
>> -rw-rw-r-- 1 root wheel 995 Aug 14 09:53 Info.plist
>> drwxr-xr-x 3 root wheel 102 Aug 14 09:53 MacOS
>>
>> HTH
>
> Well, this is still some macOS specific code that assumes that the
> support file (in this case 'help_dialog.html') is in the bundle's
> Resources folder, but we don't do this anymore since the redesign of the
> test/demo app and introduction of the data/ directory.
>
> I'm not sure what to suggest to fix this.

Could cmake add a special mac build step that on creation of the app,
also creates the help_dialog.app/Contents/Resources subdir and copies
the html file into it?

Since Resources I think is how Apple suggests packaging files
that an app depends on (along with icons, language files, config files, etc)
I expect we should try to preserve this for the demo.

> Although we could fix the issue on macOS by packaging all support files
> in their respective bundles this wouldn't solve the issue for any other
> platform

For the other platforms, I suppose we could just have a data subdir
and the executable's code could use, pseudocode:

htmlfile = directory(argv[0]) + "/data/help_dialog.html"

..with the directory hierarchy being:

<build>/bin/help_dialog.exe
<build>/bin/data/help_dialog.html

And if we wanted to standardize this across all platforms, then
there wouldn't need to be #ifdef's in the code.

Thing is it /might/ be good that at least one app shows the
"Apple way", which means creating the Resources subdir and copying
the file into it.

[Greg Ercolano]

On 2020-08-14 17:15, Albrecht Schlosser wrote:
>>>> But if things really need to be in <build>/bin for some reason,
>>>> then I'd next hope for:
>>>>
>>>> <build>/bin/test/ <-- test executables
>>>> <build>/bin/examples/ <-- examples executables
>
> If this is so important for you, then I can try to do it. It's only one
> instruction in CMake to direct all test/* executables to the subdir.
> Sounds really easy...
>
> BUT: this needs more work to make test/demo.cxx work with all the test
> programs and their support files. I put a *lot* of work in the current
> status (which is obviously not yet complete) and I'd like to avoid this
> extra work. IMHO there are really more important things than this
> subdirectory stuff.
>
> Anyway, if it's important and more than one person ;-) wants it, I can
> try it...

Sure, I'd like to see others weigh in on this.

>
>>> I wanted to get rid of the subdirs and put the test/* executables in the
>>> bin/ dir where previously only fluid was generated to be able to use a
>>> well-known structure for test/demo so we could run fluid and all the
>>> test programs from the same directory w/o adding lots of directory
>>> handling stuff (in test/demo.cxx).
>>
>> I'm sure you've researched carefully, but I think if we don't
>> do the above, we'll have to be more specific in our docs,
>> as the autoconf/make vs cmake/make results will differ as
>> to where to find stuff. Old docs will be wrong.
>
> Please tell me where it's *documented* where all the executables and
> libs (and Windows DLL's are created) so we can fix it.

With regards to our own docs I concede there's not much,
but that's not the point. There's a lot of small references
all over the place in things not under our control, or unlikely
to be changed after the fact:

Video tutorials
Books (like Stroustrup's)
Document tutorials like Robert Arkiletian's,
Educators that wrote tutorials frozen in PDFs for their classes
My cheat page
Documentation in other languages like Matteo Lucarelli's tutorials
Online articles like http://matteolucarelli.altervista.org/fltk/fltk-linux59.pdf

Basically things that are unlikely to go away, and will probably
never be updated.

I consider the forum posts docs too, because often when new users
hit a wall, a google search ends up on forum posts.. or at least used to.
(We should probably do some string searches for articles since the server
change over to make sure google still picks them up off the forum page)
I searched the fltk.general mailing list for test/ and there were around
500 hits, and around 170 for examples/

IMHO the more we change little things, the more that old stuff
suddenly becomes stale, leading new users to frustration/confusion.

That's why I was thinking if someone writes in a post:

Try the test/hello program

..that wouldn't really be "wrong" in our new cmake builds
if the directory structure were <build>/test/hello.exe

I tend to weigh in on this with enthusiasm because we run into
these same problems in film production; changing a file server path
breaks old scripts/Makefiles/projects.

Another thing I think is important is where fltk-config and fluid
end up, since those are often hard coded into developer's makefiles.
And they're going to assume fltk-config is in the top level,
and fluid in fluid/fluid.

It's interesting that in that recent post where someone ran cmake
in the top level directory, that actually gave a result very similar
to the results of autoconf/configure, which I of course think is great!
fltk-config did in fact end up in the top level dir, and even
'cd examples; make' worked. That's cool!

>>> Therefore I'd *really* like to keep the created fluid and test/*.cxx
>>> executables all together in one directory. Otherwise we'd need to
>>> revisit test/demo.cxx to sort that out again.

But if no one else feels strongly, I'll yield; just trying to avoid
breakage for what's out there.. small changes by us make headaches for
the folks "out there".

It would be great if in the end, people wanting old autoconf/make results
from cmake just have to remember to run:

cmake [-D <OPTION>=xxx]

..in the top level directory instead of 'configure', they can get the
same results they used to.

>> OK, but if we go this route, I'd /highly/ recommend a small banner
>> at the end of the build process saying where stuff is:
>>
>> --- COMPLETED
>> To build examples, run 'make examples'.
>> LIBS: ./lib
>> BINS: ./bin (fltk-config, fluid..)
>> TEST PROGRAMS: ./bin (e.g. demo, hello, etc)
>> EXAMPLE PROGRAMS: ./bin (e.g. tree-simple, etc)
>
> We can *maybe* do something like this after the CMake configure/generate
> process, similar to what `./configure` does, but probably not after the
> build (`make`) process.

OK, I guess that's just icing on the cake, and maybe it can be looked
into once cmake is stabilized.

But I think it's an important esp after a big change from
configure -> cmake to help users with a little message about where
to find stuff, just to help them along.

>> cmake -D OPTION_USE_SYSTEM_LIBPNG=off -D OPTION_USE_SYSTEM_ZLIB=off ..
>> make -j 4
>>
>> ..and it looks like both wrappers and .apps are in the ./bin directory.
>
> Note: the interesting question is where the wrappers for the *examples*

> apps are (see below for how to enable these). [..]
>
> The only thing you need to do is to enable the CMake option [..] `-D FLTK_BUILD_EXAMPLES=ON`

Ah, OK -- sounds easy enough.. good news: the wrappers do appear in the same
dir as the .app dir, e.g.

ls -la bin/examples/
total 308
drwxr-xr-x. 76 root root 2584 Aug 14 19:12 .
drwxr-xr-x. 173 root root 5882 Aug 14 19:12 ..
-rwxr-xr-x. 1 root root 797 Aug 14 09:50 OpenGL3-glut-test <-- wrapper
drwxr-xr-x. 3 root root 102 Aug 14 19:12 OpenGL3-glut-test.app <-- app
-rwxr-xr-x. 1 root root 797 Aug 14 09:50 OpenGL3test
drwxr-xr-x. 3 root root 102 Aug 14 19:12 OpenGL3test.app
-rwxr-xr-x. 1 root root 797 Aug 14 09:50 browser-simple
drwxr-xr-x. 3 root root 102 Aug 14 19:12 browser-simple.app
-rwxr-xr-x. 1 root root 797 Aug 14 09:50 clipboard
drwxr-xr-x. 3 root root 102 Aug 14 19:12 clipboard.app
-rwxr-xr-x. 1 root root 797 Aug 14 09:50 draggable-group
drwxr-xr-x. 3 root root 102 Aug 14 19:12 draggable-group.app
[..]

So for example I tried bin/examples/tree-simple and it ran as expected, and didn't
background itself the way it does with 'open bin/examples/tree-simple.app'.

Works for me!

[Greg Ercolano]

Just following up on the other things I forgot to reply to:

On 2020-08-14 17:15, Albrecht Schlosser wrote:

> but think about it: where did you find the Windows DLL's
> and the shared libs and static libs? Was this really (well) documented?

Yep, that was confusing. And for a while there the names were
not the same as unix builds. I remember having to have special
commands in my own app's Makefile that would rename them.

> The new strategy is to create build (output) files in exactly two
> directories (maybe with subdirs):
>
> lib - all libs, static and dynamic

..sounds good to me.

> bin - all executable files, particularly fluid and fltk-config, but also
> all test executables (only fluid and fltk-config will be "installed")

That sounds like expected behavior, which is good.
I kinda prefer that to having it in the top level
directory, actually.

> Basically you only need to remember 'bin' and 'lib'.

That sounds good; easy!

> The next point is: where are these files installed (with `make install`)?
>
> bin - executable files (fluid, fltk-config)
> lib - all libs (static and dynamic)

Right, so when one does a make install, I'd only expect those
to be installed, and not the test or example programs.

> So, our current build directories are the same as the future *install*
> directories, and all created files are contained in these two
> directories. Isn't this better and easier to remember than the old
> autoconf mess?
>
> Et ceterum censeo: autoconf delendam esse. ;-)

LOL, maybe we can make a configure wrapper script that just runs cmake. :P

> I'd really prefer to separate the build (output) dirs from the CMake
> work dirs to *avoid* confusion.

OK

> Yes, IMHO this is bad, because (a) "mixed with some cmake cruft" is bad
> for users, and (b) because build systems like Visual Studio and Xcode
> add their own stuff as well.

Oh boy, does VS add lots of crap, tis true.

[Albrecht Schlosser]

On 8/15/20 2:38 AM Greg Ercolano wrote:
>>> Error
>>> Unable to follow the link "bin/help_dialog.app/Contents/MacOS/../Resources/help_dialog.html" - No such file or directory.
>>

>> Well, this is still some macOS specific code that assumes that the
>> support file (in this case 'help_dialog.html') is in the bundle's
>> Resources folder, but we don't do this anymore since the redesign of the
>> test/demo app and introduction of the data/ directory.
>>
>> I'm not sure what to suggest to fix this.
>
> Could cmake add a special mac build step that on creation of the app,
> also creates the help_dialog.app/Contents/Resources subdir and copies
> the html file into it?

Been there, done that, didn't work (in parts), removed that recently.
The point is that we'd need to copy *all* support files into the bundle
dirs *and* into the new data/ dir for other platforms.

> Since Resources I think is how Apple suggests packaging files
> that an app depends on (along with icons, language files, config files, etc)
> I expect we should try to preserve this for the demo.

test/demo and others are meant to test FLTK widgets and more. They are
not primarily examples to show the *user* how things can be done.

Maybe we could add something like this in the examples/ folder?

>> Although we could fix the issue on macOS by packaging all support files
>> in their respective bundles this wouldn't solve the issue for any other
>> platform
>
> For the other platforms, I suppose we could just have a data subdir
> and the executable's code could use, pseudocode:
>
> htmlfile = directory(argv[0]) + "/data/help_dialog.html"
>
> ..with the directory hierarchy being:
>
> <build>/bin/help_dialog.exe
> <build>/bin/data/help_dialog.html
>
> And if we wanted to standardize this across all platforms, then
> there wouldn't need to be #ifdef's in the code.

Been there, done that. Works on all platforms including macOS.

This was my recent redesign of the CMake build of our test programs to
make test/demo.cxx work with CMake on all platforms with less #ifdef's
in the code. Sounds familiar???

Works on all platforms including macOS - when running the executables
from the demo app which uses appropriate commandline arguments.

There's only a minor difference: the 'data' subdir is not *inside* the
'bin' directory but at the same level. Truncated tree view below:


├── bin
│   ├── examples subdir with examples/* apps, if enabled
│   │   ├── browser-simple
│   │   └── ···
│   ├── fltk-config (script)
│   ├── fluid (executable)
│   └── hello + all the other test executables ...
├── data
│   ├── browser.cxx
│   ├── demo.menu
│   ├── editor.cxx
│   ├── help_dialog.html
│   ├── images
│   │   ├── FL200.png
│   │   ├── Fl_Value_Input.png
│   │   ├── Fl_Value_Output.png
│   │   └── tiny.png
│   ├── rgb.txt
│   └── valuators.fl
...


The data/images folder is required for help_dialog. I had to change
help_dialog.cxx to make this work for both autoconf/make which runs
fltk/test/help_dialog and for CMake which runs build/bin/help_dialog
e.g. on Linux or for instance build/bin/Debug/help_dialog.exe when using
VS or Xcode. It's more complicated than one would believe at a first
glance...

It does NOT work though on *any* platform if you run the
executable/wrapper/bundle w/o a commandline argument. Making this work
would require much more work in *all* test programs that need to read an
input file (like browser, editor, colbrowser, fluid(!), etc.) with macOS
platform (bundle) specific code which makes the test programs more
complicated than necessary.

> Thing is it /might/ be good that at least one app shows the
> "Apple way", which means creating the Resources subdir and copying
> the file into it.

I agree, but IMHO this should be an example program in the examples
folder. We do have (limited) support for putting file into macOS bundles
in our CMake macro 'CREATE_EXAMPLE', but this is hard to understand for
new users. It would probably be better to do this with a single app in
its own folder (or subfolder in examples) that shows the "Apple way" to
build a bundle and the equivalent application in a cross-platform way.
This could be the topic of a separate tutorial "how to build a macOS
bundle" or something like that.

PS: if I interpret the macOS bundle "Resources" folder correctly (just
by its name) it should hold resources required to run the program rather
than files the program would "open to read and work with". Therefore I
wouldn't consider 'help_dialog.html' and the images to be *resources*.
OTOH I would consider 'demo.menu' a resource of demo.cxx/.app - although
you can also open another menu file with the demo app. Preference files
you want to bundle with your app might be another good example of
"resources". -- But that's kinda nitpicking, just to make clear what I
would consider resources and what not. But I may be totally wrong.

[Albrecht Schlosser]

On 8/15/20 4:18 AM Greg Ercolano wrote:
> On 2020-08-14 17:15, Albrecht Schlosser wrote:
>>
>> Please tell me where it's *documented* where all the executables and
>> libs (and Windows DLL's are created) so we can fix it.
>
> With regards to our own docs I concede there's not much,
> but that's not the point. There's a lot of small references
> all over the place in things not under our control, or unlikely
> to be changed after the fact:
>
> Video tutorials
> Books (like Stroustrup's)
> Document tutorials like Robert Arkiletian's,
> Educators that wrote tutorials frozen in PDFs for their classes
> My cheat page
> Documentation in other languages like Matteo Lucarelli's tutorials
> Online articles like http://matteolucarelli.altervista.org/fltk/fltk-linux59.pdf
>
> Basically things that are unlikely to go away, and will probably
> never be updated.

Sorry, I disagree. I see that such external docs exist, but if we wanted
to make everything that's externally documented work in the future w/o
changes then we couldn't use CMake at all and would have to stick with
the bundled IDE files for all times. That's not going to work.

My strong belief is that we *must* change things now for a better future
in one step and document these changes.

It's hard but it's a necessary step. Consider how Microsoft keeps their
API's "forever" which makes them so convoluted and full of exceptions
that no one can understand them and OTOH the "Apple way": they break
their own API's and remove old API's many times (remember all the
changes Manolo had to do for FLTK to *work* at all with newer macOS
versions in the recent past).

We should strive to go a way in the middle: since we changed the *build
system* anyway, let's do it now in one step when releasing 1.4.0 rather
than keeping old cruft forever. This is only true for the build system
which users must change anyway (not the FLTK API, of course).

> Another thing I think is important is where fltk-config and fluid
> end up, since those are often hard coded into developer's makefiles.
> And they're going to assume fltk-config is in the top level,
> and fluid in fluid/fluid.

Although we always recommended to build applications against the build
directory (which has always been the source directory with
autoconf/make), things have changed with the introduction of CMake:

(1) we allow and strongly recommend out of source builds

(2) we *should* recommend to use the 'install' target to install FLTK
and build apps against *installed* FLTK versions. This would for
instance simplify the issues we have with abi-version.h. This does not
mean that it must be installed in a system directory, it can also be a
local dir chosen by the user.

(3) whereever the built files (libs, fluid, fltk-config) are generated
during the build process doesn't matter if (only) the required files are
*installed* to a user selectable install directory.

(4) fltk-config will lose its importance if users build their
applications with CMake as well which is *way* easier than using
autoconf/make, BTW. CMake builds and installs config files the user can
use which simplifies the configuration of their own apps even more.

> It's interesting that in that recent post where someone ran cmake
> in the top level directory, that actually gave a result very similar
> to the results of autoconf/configure, which I of course think is great!
> fltk-config did in fact end up in the top level dir, and even
> 'cd examples; make' worked. That's cool!

No, it's not cool. If you run CMake in the source directory (with a
"Makefiles" generator), CMake does not only add all the CMake stuff,
they also overwrite Makefiles and other files that are in the git repo.
If you do this on a source tree extracted from a tarball (snapshot) this
destroys the original files and you can't recover from git. The only way
is to extract the tarball again.

Believe me, it's a PITA. Or try it yourself: run CMake in the source
directory as described above, then run autoconf/configure/make in the
same directory. Have fun!

This is why the CMake guys strongly discourage running CMake in the
source directory, and so do I. I don't want to imagine what user
questions we will get when users start doing this: why does
configure/make not work? See above for an explanation.

Honestly, I'd like to disallow running CMake in the fltk source
directory to prevent such damage. There are recipes in the 'net on how
to do this, but I'm not sure if this is necessary or wanted.

> It would be great if in the end, people wanting old autoconf/make results
> from cmake just have to remember to run:
>
> cmake [-D <OPTION>=xxx]
>
> ..in the top level directory instead of 'configure', they can get the
> same results they used to.

Please not! See above.

...

>> Note: the interesting question is where the wrappers for the *examples*
>> apps are (see below for how to enable these). [..]
>>

> So for example I tried bin/examples/tree-simple and it ran as expected, and didn't
> background itself the way it does with 'open bin/examples/tree-simple.app'.
>
> Works for me!

Thanks, that's good to know.

[Albrecht Schlosser]

On 8/15/20 4:18 AM Greg Ercolano wrote:

> On 2020-08-14 17:15, Albrecht Schlosser wrote:
>>>>> But if things really need to be in <build>/bin for some reason,
>>>>> then I'd next hope for:
>>>>>
>>>>> <build>/bin/test/ <-- test executables
>>>>> <build>/bin/examples/ <-- examples executables
>>

>> ... if it's important and more than one person ;-) wants it, I can

>> try it...
>
> Sure, I'd like to see others weigh in on this.

FWIW: I created a proof of concept and found I could do it. Tested with
Linux, MinGW (MSYS2), and VS 2019. Since Xcode obviously uses the same
(multi-config build) structure as Visual Studio I assume this works as well.

[Albrecht Schlosser]

FTR: This is the structure of files generated by CMake and VS 2019 in
Release mode:

[build/vs2019] $ tree bin data lib
bin
├── examples
│   └── Release
│   ├── browser-simple.exe
│   ├── ...
│   └── wizard-simple.exe
├── Release
│   └── fluid.exe
└── test
└── Release
├── adjuster.exe
├── ...
└── windowfocus.exe

data
├── browser.cxx
├── demo.menu
├── editor.cxx
├── help_dialog.html
├── images

│   ├── Fl_Value_Input.png
│   ├── Fl_Value_Output.png
│   ├── FL200.png
│   └── tiny.png
├── rgb.txt
└── valuators.fl
lib
└── Release
├── fltk.lib
├── fltk_forms.lib
├── fltk_gl.lib
├── fltk_images.lib
├── fltk_jpeg.lib
├── fltk_png.lib
├── fltk_z.lib
├── libfltk.dll
├── libfltk.exp
├── libfltk.lib
├── libfltk_jpeg.dll
├── libfltk_png.dll
├── libfltk_png.exp
├── libfltk_png.lib
└── libfltk_z.dll

7 directories, 150 files

[Greg Ercolano]

Sounds great -- if you want me to test anything, just lemme know which branch
and I'll give it a spin.

[Albrecht Schlosser]

Thanks, the new branch in my fork is 'feature-examples-subdir'.

You need to build the examples and after building with CMake you should
have the folders

- bin
- bin/test
- bin/examples
- data (+ subdirs)

Note that multi config builds like Visual Studio and Xcode have their
own subdirs per build type (Debug, Release, ...), e.g. bin/Debug,
bin/test/Debug, and bin/examples/Debug and the same for Release and
other build types.

Things we need to test on all platforms:

Run bin/test/demo and execute several test programs, particularly

- browser
- colbrowser
- editor
- help_dialog
- fluid
- ... and some more

I executed these tests on Windows with CMake/Visual Studio, CMake/MinGW
(MSYS2), and Linux (CMake + make and CMake + ninja).

The first 5 tests (incl. fluid) are executed with commandline args and
need to find their respective files in the 'data' folder. Other tests
just need to run and don't need any files.

Additional on macOS (which I can't do):

- build using CMake + make, run tests as above
- build using CMake + Xcode, run tests as above

Known issue on macOS: the wrapper scripts are always in the bin,
bin/test, and bin/examples folders and not in the "per build type"
subdirs Debug, Release, etc. where they belong. This will be fixed in a
later update (I think I know how to do it, but I need to implement and
test it).

TIA for testing.

[Manolo]

On Sunday, August 16, 2020 at 8:49:29 PM UTC+2 Albrecht Schlosser wrote:

Additional on macOS (which I can't do):

- build using CMake + make, run tests as above

The build runs well under macOS, and wrappers are where they are useful, next to application bundles,

both with bin/tests/and bin/examples/.

When the demo test app is run, support files of most test apps are found (editor, browser, help_dialog)

but not with colbrowser.
When these apps are run directly (i.e., not through demo) they don't find their respective support file.

- build using CMake + Xcode, run tests as above

The builds run well both in debug and release modes, and places test and example apps in

folders bin/test/Debug/, bin/test/Release/,  bin/examples/Debug/ and bin/examples/Release/ as expected.

As to whether test apps find their support files, it's as reported above.

Known issue on macOS: the wrapper scripts are always in the bin,
bin/test, and bin/examples folders and not in the "per build type"
subdirs Debug, Release, etc. where they belong.

Yes, that's what I see.

[Albrecht Schlosser]

On 8/17/20 5:08 PM Manolo wrote:
>
> On Sunday, August 16, 2020 at 8:49:29 PM UTC+2 Albrecht Schlosser wrote:
>
> Additional on macOS (which I can't do):
>
> - build using CMake + make, run tests as above
>
> The build runs well under macOS, and wrappers are where they are useful,
> next to application bundles,
> both with bin/tests/and bin/examples/.
> When the demo test app is run, support files of most test apps are found
> (editor, browser, help_dialog)
> but not with colbrowser.

OK, thanks. I see what's causing this and I'll fix it.

> When these apps are run directly (i.e., not through demo) they don't
> find their respective support file.

This is so on all platforms now. All these programs need a commandline
argument (can be a relative path except with macOS bundles as we know)
*or* the required file must be in the current working directory (which
doesn't work with bundles but with the wrapper scripts IIRC).

[...]

Thanks for your tests and the feedback.

[Albrecht Schlosser]

On 8/17/20 6:56 PM Albrecht Schlosser wrote:
> On 8/17/20 5:08 PM Manolo wrote:
>>
>> The build runs well under macOS, and wrappers are where they are
>> useful, next to application bundles,
>> both with bin/tests/and bin/examples/.
>> When the demo test app is run, support files of most test apps are
>> found (editor, browser, help_dialog)
>> but not with colbrowser.
>
> OK, thanks. I see what's causing this and I'll fix it.

Done. With commit d91160a9e all test programs should find their files on
all build systems if executed by `demo`.

If not run by demo you need to use a proper commandline argument. The
latter may need a full path if you execute the bundle with `open` on
macOS (IIRC).