| |
| |
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.
--
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/53817d17-2eb2-8157-d9e1-57c750e223bb%40online.de.
[ Direct Link to Message ] | |
|
| |
