MacOS build patches

[p.w.wong]

Attached below are the build file patches that I used to compile version hugin-2022.0.0 to create a MacOS dmg that runs on MacOS v.10.12.6 thru Monterey (I think?). One thing to note is that if you have libjpeg-turbo installed, it will be pickup first and your build will fault with an exception in anything that uses jpeg routines. It boils down to a versioning issue in the libjpeg-turbo header (it reports version 8) and the jpeg routines in this build process (needs something other than reporting version 8). So rename the libjpeg-turbo headers and it will be fine.

[tmodes (tmodes)]

Please regenerate the patch against current head of default branch. It contains already some the your changes.

Second, please check the patch again. (e.g. CC="/opt/local//bin/clang" has a double slash instead of a single one)

And third and the main issue: please consolidate your efforts for the Mac builds with other builders. I opened a thread in the mailing list https://groups.google.com/g/hugin-ptx/c/ssEQpNf7-Co

[p.w.wong (phil-weballey)]

On 7/25/23 1:38 PM, tmodes wrote:
> Please regenerate the patch against current head of default branch. It
> contains already some the your changes.
>
> Second, please check the patch again. (e.g. CC="/opt/local//bin/clang"
> has a double slash instead of a single one)
>
> And third and the main issue: please consolidate your efforts for the
> Mac builds with other builders. I opened a thread in the mailing list
> https://groups.google.com/g/hugin-ptx/c/ssEQpNf7-Co
>
>
> ** Changed in: hugin
> Status: New => Incomplete
>

Looks like to don't have reply permissions to this group. I can add my
comments once I have permissions.

(But basically the compiler toolchain that I used is from macports. Its
my impression that the origin of clang shouldn't matter since the final
dmg is self contained.)

-phil

--
"Pretending that the all-but-inevitable is inconceivable doesn't
make it impossible."

Phillip W. Wong, PE (<email address hidden>)

[tmodes (tmodes)]

The group is public. Maybe you need to join the group before you can answer.

Just some comments here:
* the compiler paths: yes, it does not matter for the final package. But it matters for the build script. Currently each builder is using a different path. Either reach an agreement that works for all. Or alternatively you could also use an environment variable with the compiler path and check in the script if the variable is set (and if not stop processing).
But currently I don't know which path should go into the public repo.

* Update build scripts for newer versions of some dependencies. This are the easiest one. Ideally it should work for a broad range of version. But also a working version for (only) the latest version is ok.

* Compiling for different architectures: there is the set for x64 which you updated, right? Then there is an update from Erkan Ozgur Yilma https://sourceforge.net/p/hugin/hugin/merge-requests/4/ for the Apple M1/M2 architecture. These both patch overwrite some parameters each others.
Ideally both should be combined and the architecture being configurable at runtime from the scripts (e.g. a command line switch or an environment variable or…) But this needs some work and testing from the Mac builder side.
I know it is some work. But otherwise there are 2 conflicting sets of parameters which will overwriting each other in each patch/merge request from your 2 sides.

[p.w.wong (phil-weballey)]

On 8/4/23 11:38 AM, tmodes wrote:
> The group is public. Maybe you need to join the group before you can
> answer.
>
> Just some comments here:
> * the compiler paths: yes, it does not matter for the final package. But it matters for the build script. Currently each builder is using a different path. Either reach an agreement that works for all. Or alternatively you could also use an environment variable with the compiler path and check in the script if the variable is set (and if not stop processing).
> But currently I don't know which path should go into the public repo.

I'm not sure of what to choose for the repo, since it appears that the
orginal README.md has instructions for installing llvm via homebrew. I
am using macports which uses a different set of compiler paths and
didn't want to mess up my system with another package system, so I
adjusted the CC and CXX to work with the what I had.

Maybe this can be resolved by updating to README.md to state that the CC
and CXX paths need to be modified according to whether homebrew or
macports is used to install llvm?

>
> * Update build scripts for newer versions of some dependencies. This are
> the easiest one. Ideally it should work for a broad range of version.
> But also a working version for (only) the latest version is ok.
>
> * Compiling for different architectures: there is the set for x64 which you updated, right? Then there is an update from Erkan Ozgur Yilma https://sourceforge.net/p/hugin/hugin/merge-requests/4/ for the Apple M1/M2 architecture. These both patch overwrite some parameters each others.

This is for x64. I have no M1 to test on.

> Ideally both should be combined and the architecture being configurable at runtime from the scripts (e.g. a command line switch or an environment variable or…) But this needs some work and testing from the Mac builder side.
> I know it is some work. But otherwise there are 2 conflicting sets of parameters which will overwriting each other in each patch/merge request from your 2 sides.
>

Strictly speaking, the paths for homebrew are the correct one, since the
README.md says to install cmake and llvm via homebrew.

-phil

--
"Pretending that the all-but-inevitable is inconceivable doesn't
make it impossible."

Phillip W. Wong, PE (<email address hidden>)

[Launchpad Janitor (janitor)]

[Expired for Hugin because there has been no activity for 60 days.]