CMake/Xcode proposed change(s)

[melcher....@googlemail.com]

Hi devs,

because I have not contributed anything in such a long time, I wanted to ask first before making changes.

Short term, I would love to update Fluid (fix all STRs, make it use Fl_Tree, add Fl_Grid, etc.), so I want to add the header files to be visible in the IDE. Should I commit directly to fltk/fltk for major milestones, or would you prefer Pull Requests?

For example, I would like to add   set (CMAKE_XCODE_GENERATE_SCHEME 1) to line 72 in CMake/setup.cmake. This keeps Xcode form asking to rebuild all schemes after every CMake change and simply rebuilds them. The disadvantage is, that it overwrites custom schemes, which only Core developers would use. Is anyone carefully crafting schemes, or can I commit this change?

If the Fluid upgrade works out, I may feel confident enough to get Nano/Pico up to date and implement SDL/Framebuffer/Android rendering correctly.

Matthias 

[Albrecht Schlosser]

On 11/30/21 2:08 PM 'melcher....@googlemail.com' via fltk.coredev wrote:

Hi devs,

Hi Matthias,

because I have not contributed anything in such a long time, I wanted to ask first before making changes.

Short term, I would love to update Fluid (fix all STRs,

That would be very much appreciated. I believe that no other active dev knows fluid as good as you do.

make it use Fl_Tree,

That would be "nice to have". If it's doable short-term, this would be fine. OTOH ...

We're striving to get FLTK 1.4.0 released in January or February (more likely the latter) of 2022, at least the first RC(s).

add Fl_Grid,

Fl_Grid is not yet ready for production but I hope to get there soon.

One of my major concerns was "how would I add it to fluid?". It would be awesome if you could do this - but please be aware that the API is not yet stable. It's still in an experimental status and the API may change significantly. We should also try to do more testing and evaluation by devs before we declare the API stable.

Any help, testing, comments (in my Fl_Grid thread here in fltk.coredev or on GitHub issue #256) would be appreciated.
https://github.com/fltk/fltk/issues/256

etc.), so I want to add the header files to be visible in the IDE.

Hmm, what exactly does this mean (in practice), and which IDE(s) ?

Should I commit directly to fltk/fltk for major milestones, or would you prefer Pull Requests?

Personally I prefer to work in a separate fork in a specific branch for each major change. The big advantage is that you can rebase and squash changes before you push to the FLTK repo. The net result is that the public FLTK repo doesn't get many, many changes of the same file(s) which should make the repo smaller and less stuff to download for users cloning the repo.

Using a PR can be a (pre-)final step to discuss changes. Before that we can all pull changes from your fork for testing.

FWIW: I'm pushing my Fl_Grid changes to my own fork/branch and I intend to squash (`rebase -i`) this branch from time to time before I push it to the FLTK repo.

For example, I would like to add   set (CMAKE_XCODE_GENERATE_SCHEME 1) to line 72 in CMake/setup.cmake. This keeps Xcode form asking to rebuild all schemes after every CMake change and simply rebuilds them. The disadvantage is, that it overwrites custom schemes, which only Core developers would use. Is anyone carefully crafting schemes, or can I commit this change?

I'm personally not working with Xcode at all and I do not even know what Xcode "schemes" are. If I try to test the FLTK build with Xcode (rarely) I just confirm the question to create the schemes. If this change would affect users you could also make it an option or we could document that users could set this variable to ON or OFF in their cmake commands.

If you change CMake code, please make sure that it is compatible with our minimum CMake requirements, currently

   'cmake_minimum_required (VERSION 3.2.3 FATAL_ERROR)'

If that's a problem: I built several CMake versions from scratch and installed these in separate /usr/local/cmake-3.x.y folders on my Linux system. It's not hard to do this and CMake remembers the version of CMake you used to create the build files so you can always regenerate the build with the original version.

If the Fluid upgrade works out, I may feel confident enough to get Nano/Pico up to date and implement SDL/Framebuffer/Android rendering correctly.

This would be "the future", supposedly after the release of 1.4.0 (IMHO)?. I suggest to do such work in your own fork and to only push "milestones" (squashed and rebased) to the main FLTK repo once there is enough progress to publish it.

Note: This is my personal opinion because I like to keep a "clean" FLTK repository with a clean history w/o many incomplete and experimental changes.

Thanks for reading so far. ;-)

[Greg Ercolano]

On 11/30/21 5:08 AM, 'melcher....@googlemail.com' via fltk.coredev wrote:

Hi devs,

because I have not contributed anything in such a long time, I wanted to ask first before making changes.

Short term, I would love to update Fluid (fix all STRs, make it use Fl_Tree, add Fl_Grid, etc.), so I want to add the header files to be visible in the IDE. Should I commit directly to fltk/fltk for major milestones, or would you prefer Pull Requests?

    I defer to Albrecht, but I'd offer my 2 cents: go for full access and make
    branches off master if it's a big change (as you've done in the past with
    svn previously)

    Git makes this easy, and you can either squash the branch into a single commit,
    or keep all the branch commits for a history of development.

    I find the easiest thing to do is open an issue on fltk and then solve it yourself,
    even ask/answer questions yourself, just so there's a record of the evolution.
    Then merge the branch later to "solve" the issue, referencing the issue# in
    the final commit, as we've done in the past with STR's, so commits have a
    body of text describing what led to the commit.

    For a long development processes with lots of back+forth texts from other devs,
    an "issue" is better to track the discussion, and then when you commit the final
    merge, the reference to the issue brings the code and discussion together as one.

    For changes to cmake, sync with Albrecht as he's been the lead on cmake
    development, and is actively developing to get ready for a 1.4.0 release,
    whose time table is always imminent.

    I don't think anyone's claimed fluid as their own thing to manage, you're
    probably the one that's done the most work on it and understands it best
    IIRC, so you know it better than anyone..! I hacked on it a little to add
    external text editor support and line numbers in the native code windows,
    and perhaps some other small things, can't remember. Been a while.

If the Fluid upgrade works out, I may feel confident enough to get Nano/Pico up to date and implement SDL/Framebuffer/Android rendering correctly.

    Be sure to sync up with manolo's recent contributions to the system driver
    interface (I think you are already, perhaps even worked together on it).

    Sure, we could use the man power on FLTK dev.
    Confidence comes with practice, so I think it'd be good you just jump in
    with two feet. If anything goes crazy with git, Albrecht can help, as he seems
    to know it better than any of us.

[Albrecht Schlosser]

[ Top-posting intentionally ]

I agree with Greg in all points. Our messages crossed in time, so ...

please let me summarize what I think is consent:

- *always* work in a development branch, update your local 'master'
before and after pushing, rebase your dev branch on master right before
pushing your commits to fltk/fltk on master

- for small updates and bug fixes, go for direct commits and push to
fltk/fltk (as written above)

- for bigger work, prepare everything in a branch in your own fork

- checkout your fork/master and pull from 'upstream' from time to time
as needed, then ...

- rebase (-i) your fork/branch on master (squashing commits if useful)

- please don't merge fltk/master "downstream" into your branch. This
will produce chaos (repeated commits, hard to read history, etc.)

- please take care to set your editor to the correct indenting with two
spaces (we banned tabs from source files)

- GitHub issues and PR's are useful tools, use as appropriate (as Greg said)

Something related to Git: git has a new config which you can set to
avoid unintentional merges if you committed to your local master and
need to pull from upstream master. I *strongly* recommend to set this:

$ git config --global pull.ff only

This prevents you from merging upstream into your own (supposedly
master) branch and issues a warning instead. If you get this warning (on
`git pull`) you can use

$ git pull --rebase

to fix this situation (rather than `git pull`). This will update your
local master from the remote master *and* rebase your own master branch
on top of the remote master branch. After this you can fix potential
merge conflicts, test your now rebased branch, and push your commits
upstream as intended with

$ git push

HTH.

[ End of message ]

[Manolo]

Le mardi 30 novembre 2021 à 14:08:38 UTC+1, melcher....@googlemail.com a écrit :

Hi devs,

…

For example, I would like to add   set (CMAKE_XCODE_GENERATE_SCHEME 1) to line 72 in CMake/setup.cmake. This keeps Xcode form asking to rebuild all schemes after every CMake change and simply rebuilds them. The disadvantage is, that it overwrites custom schemes, which only Core developers would use. Is anyone carefully crafting schemes, or can I commit this change?

I use Xcode intensively, but not CMake-created projects. Instead, I use projects tweaked from the XCode FLTK project

that used to be part of the FLTK source tree.

Thus, no obstacle on my side for you to commit this change.

[melcher....@googlemail.com]

Thanks guys. I just tried the first commit and for reasons that I don't understand, it also pushed "Merge branch 'fltk:master' into master". Albrecht, could you please check if this reversed Manolo's changes (I don't think so) and reverse if I ruined anything. Bad start :-( .

I will try another branch now in GitHub.com/MatthiasWM/fltk for polishing Fluid. Let's see how that will go ;-) .

[Albrecht Schlosser]

On 12/3/21 9:06 PM 'melcher....@googlemail.com' via fltk.coredev wrote:

Thanks guys. I just tried the first commit and for reasons that I don't understand, it also pushed "Merge branch 'fltk:master' into master". Albrecht, could you please check if this reversed Manolo's changes (I don't think so) and reverse if I ruined anything. Bad start :-( .

What happened is a known problem which I'll explain below. The good news is that it didn't ruin anything although it's annoying and confusing people.

Please read further ...

Did you commit your changes using Xcode? What happened looks exactly like what happened to Manolo when he started pushing commits with Xcode, IIRC.

The problem arises if you commit to your local master branch and try to push your 'master' to the fltk repo after someone else did already push a commit to fltk/master. Now you have two different commits with the same parent (in the simplest form).

Maybe git told you that it refused to push your commit because your branch and the remote branch had diverged and suggested to execute `git pull`. Please don't do that! If you did it, this created the "merge commit" we saw. It pulled the existing (remote) master and merged it onto your commit. After that your push sends both your commit and this "unintended merge commit" and that's what you can see now.

Maybe you did not do this explicitly, maybe Xcode did this all for you, I don't know. Certainly Manolo will know what he did to avoid this issue.

The better and recommended way out of this situation is to use

$ git pull --rebase

as I wrote recently. This pulls the remote 'master' branch and rebases your commit(s) on top of the remote master branch which is likely what you intended.


Please read again what I posted on Nov 30 (20:50 CET):

Something related to Git: git has a new config which you can set to avoid unintentional merges if you committed to your local master and need to pull from upstream master. I *strongly* recommend to set this:

$ git config --global pull.ff only

This prevents you from merging upstream into your own (supposedly master) branch and issues a warning instead. If you get this warning (on `git pull`) you can use

$ git pull --rebase

to fix this situation (rather than `git pull`). This will update your local master from the remote master *and* rebase your own master branch on top of the remote master branch. After this you can fix potential merge conflicts, test your now rebased branch, and push your commits upstream as intended with

$ git push

(end of citation).

There are other hints in this message which are worth reading!


I hope that this will also prevent Xcode from doing what it might have done with your recent commit on your behalf. Please let me know if this helps and/or if you have further questions.

Thanks
Albrecht

[melcher....@googlemail.com]

Yes, Xcode, and yes, I read you mai and did the git config --global pull.ff only  , but I I am afraid it doesn't fix Xcode, and I don't really want to try it either. Xcode does the typical Mac thing: it looks simple and easy on the outside, but gives the user no clue on what is happening inside. Sorry about the noise.

[Albrecht Schlosser]

On 12/4/21 12:25 AM 'melcher....@googlemail.com' via fltk.coredev wrote:

Yes, Xcode, and yes, I read you mai and did the git config --global pull.ff only  , but I I am afraid it doesn't fix Xcode, and I don't really want to try it either. Xcode does the typical Mac thing: it looks simple and easy on the outside, but gives the user no clue on what is happening inside. Sorry about the noise.

Oh, that's a pity. I can't tell what Manolo is doing, maybe he can shed some light on it...

I believe you can do both in parallel, i.e. use Xcode but prepare the git repo with the command line. This may look silly but it will very likely work.

What I would do is:

(1) work with Xcode if you like, but use a branch for everything, maybe commit more than one commit to that branch, that's all OK.

(2) before you push your changes, use the commandline or whatever to pull the remote master branch:

$ git checkout master
$ git pull

(3) rebase your changes (your 'working' branch) on master:

$ git rebase master working   # leaves you on branch 'working'

(4) checkout master again and "merge" your working branch on top of it

$ git checkout master
$ git merge --ff-only working

(5) if this succeeds, push master

$ git push [origin master]

That's what I'm doing if I'm working on a long running branch.

OTOH, for a small fix, you can commit directly to your master branch:

$ git checkout master
[work ...]
$ git commit
[get master and rebase your own commit on top of it:]
$ git pull --rebase
[push your work:]
$ git push

That's much simpler and you can use it for "quick" commits easily. The key is to commit to branch 'master' but to use `git pull --rebase` before you push your work to the remote repo.

That said, I don't know how you can combine this with working in Xcode.

Again, maybe Manolo can help. Manolo, can you tell us how you are working now? Are you still using Xcode?

[melcher....@googlemail.com]

Ok, that helps a lot already. I have one additionally hurdle though. My origin is GitHub.com/MatthiasWM/fltk/matt_fluid_fixed , which is a branch of a fork of GitHub.com/fltk/fltk, which I set as the Upstream (following the GitHub tutorials). Since nobody else pushed to my repo, Xcode seems to be good enough (but I have to remember to push to origin and not to upstream, which Xcode sometimes defaults to).

I'll try to adapt my next commit to your system.

[Manolo]

Le samedi 4 décembre 2021 à 01:10:32 UTC+1, Albrecht Schlosser a écrit :

Again, maybe Manolo can help. Manolo, can you tell us how you are working now? Are you still using Xcode?

Yes, I use Xcode as much as possible.

I find it works smoothly with git as long as you don't forget to pull from the public FLTK repo just before

asking Xcode to push. If you forget, you provoke extra "merge commits" that are less desirable.

It's also fine to do, in Xcode :

-commit

-pull

      activate option "stash local changes"

-push

The bad scenario is:

-commit

-push

when your local repo is behind the main repo.

This works also with a private git repo forked from the main one.

One has to pay attention when push'ing because Xcode allows to push

to both repos.

[Albrecht Schlosser]

Thanks, Manolo, that's exactly what I wanted to know and which can hopefully help Matthias and others.

[Bill Spitzak]

I always use "pull --rebase" as it also makes your local set of commits sensible. You may have to hand-edit a few patches but I have certainly found this actually is good for detecting conflicts, especially cases where your changes have been duplicated or are no longer relevant. There is a git setting so that pull does this all the time.

There is a way to set git so it refuses to do any push other than a "fast forward", which basically means you must do a pull --rebase and then push while nobody else changes the branch (should only be a problem for people actually making final merges to the development branch).

These are just my opinions but I have found git far easier to deal with by keeping a single thread of commits as much as possible.

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/d25ced2f-e56b-9326-e2f0-b5b369e8614f%40online.de.