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!

-- 
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/c4661cf2-5c78-c380-a4d8-ba529da024e6%40seriss.com.