Production version recommendation

[Rob McDonald]

Some of my users are reporting problems with MacOS Big Sur.  It looks like these have been addressed with some of the recent work by Manolo and the team.

I am currently using 1.3.5 with no patches.  I'd prefer to stick with a stable version in general as it makes everyone's life a bit easier.

Article #1611 says that 1.3.X is still receiving MacOS related fixes, but other comments indicate that it is pretty stagnant.

1.4.X seems to have no particular path to a .0 release.  I am reluctant to grab master on a random day as you never know if that will relatively stable or in the middle of a mess.

So, what is the current recommendation?  Use the tip of branch-1.3?  Use the tip of master?  Use some random SHA version that is known to be 'pretty good'?

Is there an uncharted plan for 1.4.0?  1.3.5 was 20+ months ago

Best,

Rob

[Albrecht Schlosser]

On 11/22/20 10:15 PM Rob McDonald wrote:
> Some of my users are reporting problems with MacOS Big Sur.  It looks
> like these have been addressed with some of the recent work by Manolo
> and the team.
>
> I am currently using 1.3.5 with no patches.  I'd prefer to stick with a
> stable version in general as it makes everyone's life a bit easier.
>

> Article #1611 <https://www.fltk.org/articles.php?L1611> says that 1.3.X

> is still receiving MacOS related fixes, but other comments indicate that
> it is pretty stagnant.

I'd like to release 1.3.6 maybe this year or at the beginning of 2021.
I'm currently working on backporting some CMake modifications,
particularly addressing Windows DLL builds but also other stuff. This
should definitely go into 1.3.6.

We have 26 commits in branch-1.3 since the release of 1.3.5. Many of
these commits are related to macOS.

I can't speak for Manolo, but since the new Apple M1 processor is
available there may be some necessary fixes for macOS as well (or not,
who knows?).

All that could likely be achieved during the next weeks/months so that
we can hopefully release 1.3.6 as I wrote above. There's no defined plan
or schedule however yet.

> 1.4.X seems to have no particular path to a .0 release.  I am reluctant
> to grab master on a random day as you never know if that will relatively
> stable or in the middle of a mess.

You could pick a version that "looks good" (read the commit logs) and
watch the further development. Then test this version with your
application(s) and watch for further commits that may be relevant to you
or fix issues you see when testing. If everything is fine, use this
release for production code.

> So, what is the current recommendation?  Use the tip of branch-1.3?  Use
> the tip of master?  Use some random SHA version that is known to be
> 'pretty good'?

The tip of 1.3 should be pretty stable as there are no new features but
there are also fixes that may have introduced new bugs. Probably not
much though but there have been no release candidates and hence no wide
testing. If you can wait until the beginning of 2021 chances are that
there will be a 1.3.6 release with one or more RC's.

> Is there an uncharted plan for 1.4.0?  1.3.5 was 20+ months ago

My opinion is that 1.4.0 still needs some improvements and I'm working
on some of them. Before we release 1.4.0 there should also be a thorough
code review and there are some "FIXME" comments that should be reviewed
and maybe fixed. It's still in progress.

That said, I'd suggest to start with the tip of branch-1.3, test your
app (as if this was a RC) and wait for upcoming changes for CMake and
macOS and then for release 1.3.6.

I would also give git master (1.4.x) a go to see if this works for you.
The code is really mostly API compatible and the few differences can be
made compatible, for instance using the correct include files. Both
versions are slightly different in their requirements but if you include
the *correct* headers everything should be fine with both versions (no
need to #ifdef ...). I intend to improve the docs with hints what to do.
If you find any regressions you're invited to report these in
fltk.coredev. TIA.

[w1hkj]

I have over 10,000 users of a suite of amateur radio Emergency Communications programs.  Many of the users are associated with the American Red Cross.  I distribute source, Windows installation binaries and OS-X / macOS disk image files (dmgs), http://www.w1hkj.com.  The flagship program, fldigi, has been in development with many releases over the last 18 years.  All of the programs use Fltk as the UI library.  Fltk-1.3.5 produces excellent binaries for G4 (Motorola), i386, and x86_64 OS-X/macOS targets, up to and including 10.15.x.  Those same binaries will not run on Big Sur, 11.x.  The code executes, but the UI produces blank dialogs.  My macOS testers report that the same code linked to Fltk-1.4.x (latest git commit) will run and display correctly, but not for every combination of display / video h/w.  My three M1 platform testers report that Rosetta-2 fails to produce a fulfilling run-time for both the 1.3.5 and 1.4.0 Fltk builds.  One of the M1 testers is a member of my development team.  I expect he will be able to provide us with additional insight.  I've asked him to create a full build suite on the M1 system.  Fltk first of course.

Apple seems intent on making life difficult for third party developers.  I am grateful for all of the work that the Fltk developer/maintainer team puts forth.  Thank you.

David

[Manolo]

Both FLTK 1.3 and 1.4 should run correctly under macOS 11.0 "Big Sur", at least with Intel hardware.

In both cases, the last version in the git repository is necessary, because macOS 11.0 contains

an OS change that made it incompatible with the public version 1.3.5.

[imm]

(I don't have a Mac capable of running Big Sur, so this is all unknown to me...)

Manolo, is there some "best practice" for building an application to run correctly under both OS11 and OSX?

I have a sense, from the reports, that folk are finding that what they normally build works on one but not the other...

Is there a SDK setting or such that is needed, for example?

-- 
Ian
From my Fairphone FP3

[w1hkj]

Thank you Manolo.  I will build with the repository 1.3.5.  Just one issue in accessing the 1.3.5 git branch for local use:

dave@m90p:~/dev.git/fltk-rev$ git branch
* master
dave@m90p:~/dev.git/fltk-rev$ git branch --all
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/branch-1.0
  remotes/origin/branch-1.1
  remotes/origin/branch-1.3
  remotes/origin/master
dave@m90p:~/dev.git/fltk-rev$ git checkout -b b1.3 origin/branch-1.3
error: The following untracked working tree files would be overwritten by checkout:
    documentation/src/fltk-book.tex.in
Please move or remove them before you switch branches.
Aborting

Renaming the offending file allowed me to create the local branch.

dave@m90p:~/dev.git/fltk-rev$ git checkout -b b1.3 origin/branch-1.3
Branch 'b1.3' set up to track remote branch 'branch-1.3' from 'origin'.
Switched to a new branch 'b1.3'

David

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/fb32bf44-72b2-4a3e-817f-b170e57c363bn%40googlegroups.com.

[Manolo]

On Monday, November 23, 2020 at 11:28:47 AM UTC+1 Ian MacArthur wrote:

Manolo, is there some "best practice" for building an application to run correctly under both OS11 and OSX?

 

In general, FLTK built under macOS is very widely  upward and downward compatible.
For example, I've just built FLTK 1.4 on my macOS 11-running  computer using the 10.10 SDK,

and the resulting executable runs on "Big Sur", that is, macOS 11.0

Thus, you can use the latest SDK version that is convenient for you.

The problems happen when a new macOS version appears. They tend to contain "innovations"

that break FLTK until the source code is modified to account for those innovations.

Thus, the source code before the public beta macOS version appears may fail on a new macOS.

Hopefully, it's rapidly patched and becomes upward and downward compatible with macOS.
But it's impossible to support a future macOS before having seen it.

[Francesco Piscani]

I had been a holdout on making the jump into the newer versions. I just built FLTK 1.4.x for the first time yesterday.  I built it using MinGW, and also did it using the Visual Studio compiler.  The process went very well.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/3bd9285f-4f10-4ca7-835f-5b07811d5146n%40googlegroups.com.

[Gonzalo Garramuño]

El 22/11/20 a las 20:25, w1hkj escribió:

My macOS testers report that the same code linked to Fltk-1.4.x (latest git commit) will run and display correctly, but not for every combination of display / video h/w. 

I am curious.  What combo of display / video h/w does not work with BigSur/fltk1.4?

My three M1 platform testers report that Rosetta-2 fails to produce a fulfilling run-time for both the 1.3.5 and 1.4.0 Fltk builds.  One of the M1 testers is a member of my development team.  I expect he will be able to provide us with additional insight.  I've asked him to create a full build suite on the M1 system.  Fltk first of course.

This is bad.  Hope Apple will fix it soon.

[Albrecht Schlosser]

On 11/23/20 11:42 AM w1hkj wrote:
> ...  Just one

> issue in accessing the 1.3.5 git branch for local use:

> ...

> dave@m90p:~/dev.git/fltk-rev$ git checkout -b b1.3 origin/branch-1.3
> error: The following untracked working tree files would be overwritten
> by checkout:
>     documentation/src/fltk-book.tex.in
> Please move or remove them before you switch branches.
> Aborting
>
> Renaming the offending file allowed me to create the local branch.

FYI: documentation/src/fltk-book.tex.in is a generated file in FLTK 1.4
(master) whereas it was a source file (included in git) in FLTK 1.3
(branch-1.3). In 1.4 this file is created for instance when you run
`make pdf` in the 'documentation' folder.

Solution 1 (preferred): to avoid polluting the build directory in the
first place use CMake in an out-of-source build, e.g. in a subdirectory
(build) or anywhere else. Admittedly CMake support in 1.3 is not yet
complete, so you may want to use ...

Solution 2: always start with a *clean* working directory before you
switch branches (unless you know what you're doing and a non-clean
working copy is intended).

$ make distclean

should do the job, but if you really want to run a separate build it's
often better to use a fresh clone or (as I'm routinely doing) use `git
worktree` [1] to create a clean working tree from the *same* local git
repository.

Another way to clean your working copy is to use `git clean` [2].

HTH.

Thanks for the report anyway, but there's nothing we can or need to do
to "fix" this.

[1] $ git help worktree
[2] $ git help clean

[Manolo]

About how to build FLTK for the macOS platform :

I should add it's necessary to determine the minimal macOS version the resulting

app is required to support, and to give that information in the

"macOS deployment target" parameter under Xcode, or, with CMake, in

CMAKE_OSX_DEPLOYMENT_TARGET.

FLTK, both 1.3 and 1.4, are compatible with all versions between 10.3 and 11.0

[w1hkj]

I published a build against the latest 1.3.5 git commit for all of the EMCOMM applications

• comptext-1.0.3.2_x86_64_bs.dmg
• comptty-1.0.3.2_x86_64_bs.dmg
• flaa-1.0.3.01_x86_64_bs.dmg
• flamp-2.2.05.03_x86_64_bs.dmg
• flcluster-1.0.5.1_x86_64_bs.dmg
• fldigi-4.1.16.02_x86_64_bs.dmg
• fllog-1.2.6_x86_64_bs.dmg
• flmsg-4.0.17.01_x86_64_x86_64_bs.dmg
• flnet-7.3.3_x86_64_bs.dmg
• flrig-1.3.52.11_x86_64_bs.dmg
• flwkey-1.2.4.04_x86_64_bs.dmg
• flwrap-1.3.5_x86_64_bs.dmg
• linsim-2.0.3_x86_64_bs.dmg

I expect test reports in the next few days and will share a compilation with this group.

David

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/59dfabd1-97cd-ebe8-ff31-0d317308f33d%40gmail.com.