GraphicsMagick Code

In the future, please avoid updating the top-level ChangeLog given that this is assured to cause a large merge conflict. There are many generated files which depend on ChangeLog. The HTML files are generated based on ChangeLog, and the date at the top of the ChangeLog file is used as the release date for the whole package.

For unknown reasons, all of the binary PerlMagick/t/fpx/input files were modified. Maybe Microsoft Windows did that. I will revert this change.

I see that tiff-4.7.1/cmake/Findliblzma.cmake was renamed to tiff/cmake/FindLibLZMA.cmake. Perhaps that was the old name and the old name was selected based on similarity. I will rename it to the upstream name.

I merged your your branch into main (after fixing a Magick++ compilation bug that I had created) and closed the branch so it does not show up in the branches listing.
Unlike git, Mercurial history is totally immutable. This means that the branch which was created will always be present, even though the branch has been "closed". I had to do this in order to push changes:

% hg push
pushing to GM
searching for changes
abort: push creates new remote branches: Update libtiff (1 closed)
(use 'hg push --new-branch' to create new remote branches)
GM-tiff-merge% hg push --new-branch

Luckily, it is not necessary to add options to pull.

Thanks for accepting the merge request. I'm planning to update libpng and zlib in the near future. Should I leave ChangeLog alone in future commits?

As far as I can tell there were no PerlMagick files in my commit. Is there something I should do differently to avoid this issue?

Yes, just provide proposed ChangeLog text, and I will take care of that part of the update. This is helpful since I update ChangeLog often, and many times, there will be a change of the date at the top of the ChangeLog and thus an automatic re-generation of some dependent files.

It would be perhaps better if most generated files were removed from the Mercurial repository (they would still be in distribution archives) but I am not sure what the scope of the impact would be. For example, web sites which obtain the web site files from Mercurial (e.g. as www.graphicsmagick.org does) would be impacted.

It is a mystery to me why PerlMagick/t/fpx files were updated by the the merge change set. I don't see them updated by your branch. I think I have seen this happen before. I will watch for this issue occurring again.

The Visual Studio build would be much nicer if the generated project files do not produce warnings. One of the primary causes of the warnings seems to be that the target recorded for both Release and Debug is the same as the text which shows up in the GUI as the module name.

You are a hero for doing this work!

Please make sure that you use a very descriptive branch name, especially since Mercurial does not allow changing history. The generic branch name you used for libtiff can only be used the one time. It would have been much better if it had included the libtiff version.

I asked Google this question: "mercurial how to assure that files are treated as binary" and it says that mercurial stores all files as binary. It also says:

The distinction between text and binary is primarily for user-facing tools (like hg diff), which try to show human-readable changes, but will show "binary files differ" if NUL bytes are present

That is the message I saw.

It suggests adding a "[merge-patterns]" section to .hgrc and therefore I added this to my .hgrc:

[merge-patterns]
**.fpx = binary