Photoprism build is broken on fedora 38

[tback]

1. What is not working as documented?

I'm trying to build photoprism locally on an amd64 machine running fedora38.
I want to run make ... and get some building done.
make hangs and doesn't produce any output by default.

2. How can we reproduce it?

Steps to reproduce the behavior:

1. Get a clean checkout of photoprism/photoprism.
2. Switch to the directory you just cloned.
3. Run make help
4. Make will hang.
5. Now cancel the process ^C.
6. Run make help --debug=verbose

$ make help --debug=verbose
GNU Make 4.4.1
Built for x86_64-redhat-linux-gnu
Copyright (C) 1988-2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'Makefile'...
Reading makefile '.env' (search path) (don't care) (no ~ expansion)...
Makefile:20: not recursively expanding BUILD_OS to export to shell function
Makefile:20: not recursively expanding BUILD_OS to export to shell function
Makefile:18: not recursively expanding BUILD_VERSION to export to shell function
Makefile:20: not recursively expanding BUILD_OS to export to shell function
Makefile:18: not recursively expanding BUILD_VERSION to export to shell function
Makefile:19: not recursively expanding BUILD_TAG to export to shell function
Makefile:20: not recursively expanding BUILD_OS to export to shell function
Makefile:18: not recursively expanding BUILD_VERSION to export to shell function
Makefile:19: not recursively expanding BUILD_TAG to export to shell function
Makefile:26: not recursively expanding DESTDIR to export to shell function
Makefile:17: not recursively expanding BUILD_DATE to export to shell function
Makefile:20: not recursively expanding BUILD_OS to export to shell function
Makefile:18: not recursively expanding BUILD_VERSION to export to shell function
Makefile:19: not recursively expanding BUILD_TAG to export to shell function
Makefile:26: not recursively expanding DESTDIR to export to shell function
Makefile:17: not recursively expanding BUILD_DATE to export to shell function
Makefile:21: not recursively expanding BUILD_ARCH to export to shell function
...

Now checkout the last version that shows the desired behavior:

1. Checkout the revision before 3b55977: git checkout 6654ec7786e3181cf8daf9fe1f1d90d0920a7e5b
2. Run make help

make help
which: no richgo in (/home/tback/.local/bin:/home/tback/bin:/usr/lib64/ccache:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)
For build instructions, visit <https://docs.photoprism.app/developer-guide/>.

This is the desired behavior in my case. I didn't install richgo yet.
It seems removing the export from Line 9 of the Makefile fixes this, but neither do I know the consequences of this change, nor do I know the rationale for having it there.

I think all revisions from fd19bc0 to 3b55977 show this bevior.

[lastzero]

Note that this is not a bug, as we do not guarantee that you will be able to build the software in any environment. For questions regarding our free community edition, please use GitHub Discussions. Thank you! ❤️

[tback]

It becomes more clear now that I read more about the topic:

Make has different flavors of variables (https://www.gnu.org/software/make/manual/html_node/Flavors.html).
Photoprism uses 'Conditional Variables'. Those are 'Recursively expanded variables' that are assigned if they haven't been defined before. Recursive variables are what's causing the issue and should be replaced by 'Simply Expanded Variable Assignment' that are assigned if they haven't been defined before. Unfortunately there is no syntactic sugar for this. It can be done in three lines though:

export

ifeq ($(origin VAR_1), undefined)
  VAR_1 := $(shell echo 1)
endif

[lastzero]

For reference, this is where I found the advice:

• https://unix.stackexchange.com/questions/235223/makefile-include-env-file

One of the comments there suggests setting the special target .EXPORT_ALL_VARIABLES: instead of using the export directive. Wouldn`t that be a better solution? Unfortunately, I don't have enough time right now to test all our builds to figure out what this was used for and if anything breaks when making these changes.

[tback]

No .EXPORT_ALL_VARIABLES has the same issue. Just remember the that there are two flavors of variables. Remember to google that when make hangs.

[lastzero]

Maybe we can remove this completely.... it depends, but I can't guess.... might have been added to pass values from make to subtasks, or to configure make with a local .env file to override existing variable values. I will need time to read their docs to learn more about the types of variables in make first hand.

I would recommend removing those one or two problematic lines for now if there are no more other issues! :)

[sr3dna]

I wish I found this thread earlier. I encountered the same issue and spent quite some time figuring out a similar solution as @tback suggested -- once I changed the makefile to use the ifndef...endif conditional syntax for every statement with shell command, the time to do a make drops from an hour to a few seconds.

e.g. instead of

BUILD_PATH ?= $(shell realpath "./build")

I use

ifndef BUILD_PATH
	BUILD_PATH := $(shell realpath "./build")
endif

The following article is the one that leads me to use the conditional syntax:
https://stackoverflow.com/questions/77363777/why-export-variables-with-shell-command-in-makefile-takes-a-very-long-time

I have a feeling that the issue may occur to developers who have quite a bit of stuff in their .bashrc or .zshrc files.