CasparCG / server

CasparCG Server is a Windows and Linux software used to play out professional graphics, audio and video to multiple outputs. It has been in 24/7 broadcast production since 2006. Ready-to-use downloads are available under the Releases tab https://casparcg.com.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Bug: CasparCG Server doesn't build on linux because CEF has no documentation

Ghostbird opened this issue · comments

Observed Behavior

…
[  7%] Performing build step for 'cef'
[  0%] Generating API documentation with Doxygen...
error: configuration file Doxyfile not found!
…

Expected behaviour

CasparCG server builds successfully

Steps to reproduce

On a linux machine:

  1. Install dependencies
  2. mkdir build && cd build
  3. cmake ../
  4. make -j8

Environment

  • HEAD detached from v2.3.3-lts-stable
    nothing to commit, working tree clean
  • Linux 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux
  • Debian GNU/Linux 12 (bookworm)

As a workaround, once this occurs you can do this:

mkdir -p cef-prefix/src/cef/docs
touch cef-prefix/src/cef/Doxyfile
touch cef-prefix/src/cef/docs/index.html

Now when you build, it will generate empty CEF documentation.

Are you seeing this issue with 2.3.3 or 2.4.0?

I've not seen this on either ubuntu or fedora in 2.4.0 Reproducing this requires doxygen to be installed

Oh, wow, small world. You just helped me out with companion. As noted above, it's with the tag v2.3.3-lts-stable.

Yeah, I noticed :)

Strange, the way cef was sourced changed between 2.3.3 and 2.4 with the cef-prefix path being part of the new build setup.

Either way the same build error might be happening with both, but I'm not going to try fixing it in 2.3.3.
I have fixed this for 2.4 though in 21ccd5e (extending the cef patch to remove the block where it tries to generate docs)

Thanks a lot!
I think I made a mistake with the tag. It seems that when I'm in detached head mode, the detachment tag is reported, even when I've already pulled in new commits.

When I git reset --hard v2.3.3-lts-stable I got a different result.

Confirmed fixed on latest master, so I'm closing this.