Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ffmpeg] Correctly set environment variables for gcc/clang/icc #6694

Merged
merged 3 commits into from
May 31, 2019

Conversation

cbezault
Copy link
Contributor

@cbezault cbezault commented May 30, 2019

Should enable features to actually work on non-msvc compilers for non-windows targets.
Also remove bzip2 patch from #6570 , the bzip2 feature will be fixed by a PR for the bzip port.
Seems like a lot of the features are broken because of the d suffixes on other ports, will be working on getting them all up and running.

@cbezault cbezault added the info:internal This PR or Issue was filed by the vcpkg team. label May 30, 2019
@@ -43,7 +49,11 @@ else()
set(BUILD_SCRIPT ${CMAKE_CURRENT_LIST_DIR}/build_linux.sh)
endif()

set(ENV{INCLUDE} "${CURRENT_INSTALLED_DIR}/include;$ENV{INCLUDE}")
if($CMAKE_CXX_COMPILER_ID STREQUAL "MSVC")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not understand the requirement for the if/else case here. I thought you defined SEP to get rid of those. You probably need to define two other for ENV{INCLUDE} vs ENV{CPATH} and ENV{LIB} vs ENV{LIBRARY_PATH}. But from my viewpoint this should all be doable in the first if where SEP is defined to get rid of the other 3 ifs below it. The trick will be ENV{${ENV_INCLUDE_VAR}} and setting ENV_INCLUDE_VAR either to INCLUDE or CPATH

Copy link
Contributor Author

@cbezault cbezault May 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's a reasonable refactor. The SEP already got rid of some of those ifs, GNU expects the LIBRARY_PATH var to have semicolons when targeting Windows.

@Neumann-A
Copy link
Contributor

yeah the d suffixes.... sometimes they break stuff if they are there, sometimes they are necessary for find_package to work correctly. Really annoying. PR 5543 will only ever have zero regression from a CMake perspective if all find_package calls which define a _DEBUG variable are correctly found with the correct debug suffix. The reason I made that a FATAL_ERROR and submited PRs to correct the suffixes is because it is the only clean way for external projects to have correct library linkage in a multi config generator like VS without adding unnecessary extra code to VCPKG.

@Neumann-A
Copy link
Contributor

and bzip requires the extra d:

From CMakes FindBZip2 module

    find_library(BZIP2_LIBRARY_RELEASE NAMES bz2 bzip2 ${_BZIP2_PATHS} PATH_SUFFIXES lib)
    find_library(BZIP2_LIBRARY_DEBUG NAMES bz2d bzip2d ${_BZIP2_PATHS} PATH_SUFFIXES lib)

@cbezault
Copy link
Contributor Author

cbezault commented May 30, 2019

We're going to use bzip as a test case to see if we can still support multi-config generators while also not having the d suffix and also not braking the built-in CMake modules using wrappers.

@Neumann-A
Copy link
Contributor

That is possible if you override find_library and remove comming debug suffixes from the given names. It is basically already implemented in 5543 but not for variables with _DEBUG suffix.

@Neumann-A
Copy link
Contributor

Neumann-A commented May 30, 2019

Also there was a recent issue to add a d to a library/dll name because the user had both debug and release dlls in the same folder. Although it is probably a really bad idea to install both into the same folder, users seem to have these setups. (See issue #4878)

@cbezault
Copy link
Contributor Author

/azp run

@azure-pipelines
Copy link

Pull request contains merge conflicts.

@cbezault
Copy link
Contributor Author

/azp run

1 similar comment
@cbezault
Copy link
Contributor Author

/azp run

@cbezault cbezault merged commit 9356be6 into microsoft:master May 31, 2019
@emptyVoid
Copy link
Contributor

@cbezault, this breaks build for VC.

I'm getting an error while trying to build with vcpkg install ffmpeg[x264]:

-- Building ffmpeg for Release
CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:56 (message):
    Command failed: D:/Temp/3/vcpkg/downloads/tools/msys2/msys64/usr/bin/bash.exe;--noprofile;--norc;D:/Temp/3/vcpkg/ports/ffmpeg\build.sh;D:/Temp/3/vcpkg/build
trees/ffmpeg/x64-windows-rel;D:/Temp/3/vcpkg/buildtrees/ffmpeg/src/ffmpeg-4-ba4787156f;D:/Temp/3/vcpkg/packages/ffmpeg_x64-windows;--enable-asm --enable-yasm --
disable-doc --enable-debug --enable-runtime-cpudetect --enable-gpl --disable-openssl --disable-ffmpeg --disable-ffplay --disable-ffprobe --enable-libx264 --disa
ble-opencl --disable-lzma --disable-bzlib --extra-cflags=-DHAVE_UNISTD_H=0 --disable-static --enable-shared  --extra-cflags=-MD --extra-cxxflags=-MD
    Working Directory: D:/Temp/3/vcpkg/buildtrees/ffmpeg/x64-windows-rel
    Error code: 1
    See logs for more information:
      D:\Temp\3\vcpkg\buildtrees\ffmpeg\build-x64-windows-rel-out.log

Call Stack (most recent call first):
  ports/ffmpeg/portfile.cmake:172 (vcpkg_execute_required_process)
  scripts/ports.cmake:71 (include)


Error: Building package ffmpeg:x64-windows failed with: BUILD_FAILED

Contents of build-x64-windows-rel-out.log:

=== CONFIGURING ===
ERROR: libx264 not found

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-user@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "ffbuild/config.log" produced by configure as this will help
solve the problem.

Here's what is at the end of config.log:

check_pkg_config libx264 x264 stdint.h x264.h x264_encoder_encode
test_pkg_config libx264 x264 stdint.h x264.h x264_encoder_encode
false --exists --print-errors x264
require libx264 stdint.h x264.h x264_encoder_encode -lx264  
check_lib libx264 stdint.h x264.h x264_encoder_encode -lx264  
check_func_headers stdint.h x264.h x264_encoder_encode -lx264  
test_ld cc -lx264  
test_cc
BEGIN ./ffconf.naAgpls4/test.c
    1	#include <stdint.h>
    2	#include <x264.h>
    3	#include <stdint.h>
    4	long check_x264_encoder_encode(void) { return (long) x264_encoder_encode; }
    5	int main(void) { int ret = 0;
    6	 ret |= ((intptr_t)check_x264_encoder_encode) & 0xFFFF;
    7	return ret; }
END ./ffconf.naAgpls4/test.c
cl -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_USE_MATH_DEFINES -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_WARNINGS -D_WIN32_WINNT=0x0600 -DPIC -nologo -DHAVE_UNISTD_H=0 -MD -c -Fo./ffconf.naAgpls4/test.o ./ffconf.naAgpls4/test.c
test.c
./ffconf.naAgpls4/test.c(2): fatal error C1083: Cannot open include file: 'x264.h': No such file or directory
ERROR: libx264 not found

PS: the issue resolves after reverting to the parent commit (f2e1c52).

@cbezault
Copy link
Contributor Author

cbezault commented Jun 2, 2019

Hmmmmm, it built fine on the CI, what version of VS are you running?

@emptyVoid
Copy link
Contributor

VS 2019.

@emptyVoid
Copy link
Contributor

An excerpt from the CI build log you are referring to:

-- Using source at C:/vsts/_work/1/s/buildtrees/ffmpeg/src/ffmpeg-4-ba4787156f
-- Acquiring MSYS Packages...
-- Acquiring MSYS Packages... OK
-- Building Options: --enable-asm --enable-yasm --disable-doc --enable-debug --enable-runtime-cpudetect --disable-openssl --disable-ffmpeg --disable-ffplay --disable-ffprobe --disable-libx264 --disable-opencl --disable-lzma --disable-bzlib --extra-cflags=-DHAVE_UNISTD_H=0 --disable-static --enable-shared
-- Building ffmpeg for Release
-- Building ffmpeg for Debug

I guess it builds default features only, since x264 is disabled.

@cbezault
Copy link
Contributor Author

cbezault commented Jun 2, 2019

Yup, I was about to say. We really need some way to test features.

@cbezault
Copy link
Contributor Author

cbezault commented Jun 2, 2019

I'm away from a computer right now but I'd like to try changing line 34 of the portfile.cmake to just "if(MSVC)" and try again when I'm back at a computer. If you'd like to do it now I'd appreciate it.

@emptyVoid
Copy link
Contributor

Nope, doesn't help.

@cbezault
Copy link
Contributor Author

cbezault commented Jun 2, 2019

Sigh, okay I'll add this to the list of things to investigate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
info:internal This PR or Issue was filed by the vcpkg team.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants