Compile PG from fresh git download instructions leads to compile error: no matching function for call to '__search_impl'

[artificiel]

on macOS 13.5.1, M2Pro, Xcode 14.3.1, following the instructions to build PG fails on make Release with:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__algorithm/search.h:180:10: error: no matching function for call to '__search_impl'
  return std::__search_impl(__first1, __last1, __first2, __last2, __pred, __proj, __proj).first;

complete log attached.

of-error.log

[dimitre]

I can't reproduce on my system, it is 12.6.8, M1Pro.
The differences here are the OS and processor.

I've inspected the full log and it seems to be related to the new function ofIsPathInPath, but strangely it shows another line number than what I'm seeing here.
I've pushed another change to PG to tidy up some iterators, can you please test it again ?

[artificiel]

I'm systematically working the instructions INSTALL_FROM_GITHUB (fresh machine here so I take opportunity) so the PG code is pulled alongside the OF tree, but in there the submodule points to a specific commit (I guess it should track head?):

https://github.com/openframeworks/openFrameworks/tree/master/apps

[artificiel]

and thinking about this, and the mention in the instructions that says:

As the first option can lead to unexpected results, we suggest you use the second approach.

that is not very elegant nor clear. why try to compile within the OF tree if it's so messy (I know I never managed to succeed, but I'm trying again by following the instructions).

so I'm thinking: why is it important to have the PG as a submodule? and why do we try to have users do something clunky?

if nobody does it, it's only noise, and additional work to try to support it...

it could be simply distributed as a standalone, and packaged in the releases.

[dimitre]

I agree, wondered the same. maybe it is something to aim in the future
having PG releases with version numbers, and link OF release to a specific PG release, let's say 0.12.0 uses PG v21

[artificiel]

yes, for the moment I'm thinking mostly about the "install from git" instructions, and streamlining that process. I've made an issue to discuss the specific instructions and what we want to "expose" to potential users there.

edit to add: openframeworks/openFrameworks#7609

[dimitre]

Are you still getting this issue from PG latest? thanks

[artificiel]

yes but as mentioned above it should be considered I'm following the "install from GitHub" instruction, which pulls an older submodule projectGenerator @ bdff376 so it's stuck 2 weeks ago as seen in https://github.com/openframeworks/openFrameworks/tree/master/apps

[dimitre]

ok. I think instructions are a separate issue.
As I can't reproduce on my setup I'm wondering if it is something happening in other systems too or maybe some XCode customization.
Are you using full XCode from app store ?

[artificiel]

App Store Xcode!
This machine is brand new M2pro, with just about Xcode (+command line tools) installed.

but I'm not sure how to organise the PG "source code" without being within OF -- the PG README instructions also say to download OF and get the submodule...?

[artificiel]

and to be clear it's not about the instructions themselves; the problem is the submodule in OF refers to a specific, older projectGenerator @ bdff376 PG commit: https://github.com/openframeworks/openFrameworks/tree/master/apps

[dimitre]

I'm not using this in a standard way but I can share what I am doing here.
I say it is not standard because I never use the frontend. I've been using an drag and drop app for years to build and rebuild projects, and recently started using ofbuild, so I only need the commandline.

for the commandline I usually go to $ofw/apps/projectGenerator and pull to latest (it is not the thing submodule init / update will do) and ok, we have latest there.

and I usually make changes in a parallel folder $ofw/apps/pgd to test my PRs compile them, generate projects and push when they are ok.

as a submodule it is often updated but usually I'm pulling latest to test. I think scripts to build nightly pull the latest too but I'm not sure. I too am trying to navigate this project complexity, and proposing changes that can simplify from time to time.

[ofTheo]

yes - huge +1 if we can get apothecary and projectGenerator submodules kept up to date in master

it doesn't affect the nightly builds as they always update as part of the process but it def affects people checking out from git.

[artificiel]

from the PG side, one way or another, the build instructions within the projectGenerator repo should end up pulling latest (right now they don't as they go through the OF submodule).

and from the OF side I recommend removing the concept of users build PG themselves: openframeworks/openFrameworks#7609 if there is consensus I can take a stab at re-writing the instructions (I already have 2 tweaks proposed: openframeworks/openFrameworks#7606 openframeworks/openFrameworks#7607)

(there is little value in compiling PG by hand if the PG-nightlies produce the latest possible binaries anyway.)

[artificiel]

and to make things clear: the no matching function for call to '__search_impl' error still occurs, also on a M1 with 13.4, even from head:

steps, and attached my log for the result:

rm -rf /tmp/testPG && mkdir /tmp/testPG && cd /tmp/testPG 
git clone git@github.com:openframeworks/openFrameworks.git --depth=1
cd openFrameworks
git submodule init
git submodule update
./scripts/osx/download_libs.sh
cd apps/projectGenerator/commandLine
xcodebuild -configuration Release -target commandLine CODE_SIGN_IDENTITY="" -project commandLine.xcodeproj
echo 'Press any key to update to HEAD...'; read -k1 -s
git pull origin HEAD
echo 'Press any key to re-compile...'; read -k1 -s
xcodebuild -configuration Release -target commandLine CODE_SIGN_IDENTITY="" -project commandLine.xcodeproj

PG-error-log.txt

[dimitre]

I think this one is resolved in the latest from projectGenerator. but OF submodule is not pointing to latest yet

[artificiel]

i confirm that with HEAD it compiles and links! will make a separate issue about submodule tracking.