| |
| |
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 git@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.
--
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/6fd0cfe0-3607-2ca9-27e7-bb2ac4d7a984%40online.de.
[ Direct Link to Message ] | |
|
| |
