|Summary:||Mk/Uses/compiler.mk: cannot specify more than one argument|
|Product:||Ports & Packages||Reporter:||Jan Beich <jbeich>|
|Component:||Ports Framework||Assignee:||Port Management Team <portmgr>|
|Severity:||Affects Only Me||CC:||h2+fbsdports, jhibbits, tijl|
Description Jan Beich 2015-04-22 07:39:20 UTC
Currently, USES is designed to be parsed only once. This means any conditional within the feature will only work for the first argument. A possible fix is to workaround limitation by using feature-local variable like USES=python did. Consider the following example which should default to GCC until Clang gains OpenMP support. USES= compiler:c++11-lib compiler:openmp then try $ make -V CC $ make -V compiler_ARGS
Comment 1 Baptiste Daroussin 2015-04-22 07:43:03 UTC
Try USES=compiler:c++11-lib,openmp make -Vcompiler_ARGS For passing multiple arguments How ever compiler.mk has not been design test multiple arguments, it would need a little bit of refactor
Comment 2 Jan Beich 2015-04-22 08:46:57 UTC
Created attachment 155839 [details] v0 Maybe use undocumented argument separator (comma) for simplicity. $ make USES="compiler:c++11-lib,openmp" -V IGNORE -V _COMPILER_ARGS -V compiler_ARGS features c++11-lib env openmp features c++11-lib openmp $ make USES="compiler:features,foo" -V IGNORE -V _COMPILER_ARGS -V compiler_ARGS Invalid argument "foo", valid arguments are: c++11-lib c++11-lang c11 features openmp env nestedfct c++0x gcc-c++11-lib features foo
Comment 3 Jan Beich 2015-04-22 09:12:19 UTC
Created attachment 155840 [details] v1 (In reply to Baptiste Daroussin from comment #1) > However compiler.mk has not been design test multiple arguments, it would need a little bit of refactor Would the attached patch help? Mainly to help USES= compiler:c++11-lib OPTIONS_DEFINE= OPENMP OPENMP_USES= compiler:openmp
Comment 4 Baptiste Daroussin 2015-04-22 09:14:33 UTC
I do like it, it would need an exp-run top ensure that it does not break any else
Comment 5 Jan Beich 2015-04-22 09:43:02 UTC
Note, compiler.mk still requires more work: c++11-lib + openmp != gcc-c++11-lib, i.e. broken on libc++ systems.
Comment 6 Jan Beich 2015-04-22 12:05:02 UTC
Created attachment 155845 [details] v1.1 Doh, !defined was there to catch dups like the following: devel/libsoup: Ignored: Incorrect 'USES+=tar:xz xz'
Comment 7 Jan Beich 2015-04-29 08:06:17 UTC
USES=qmake relies on current behavior. It assumes when defined by port's Makefile _env argument from bsd.qt.mk won't be passed leading to broken build: ===> Configuring for qt5-svg-5.4.1 echo 'CMAKE_MODULE_TESTS = -' > WRKSRC/.qmake.cache ===> Building for qt5-svg-5.4.1 make: cannot open Makefile. How or whether to allow empty arguments needs more thinking. For one, USES=foo == USES=foo:empty or USES=foo:foo would break those that disallow non-empty foo_ARGS such as USES=fuse.
Comment 8 Antoine Brodin 2015-04-29 08:12:02 UTC
Adding tijl@ in cc: as he reworked USES in ports r369465
Comment 9 Tijl Coosemans 2015-04-29 10:22:13 UTC
(In reply to Jan Beich from comment #6) The !defined wasn't added for duplicates. It was added just for USES=qmake. So I think you should go back to your earlier patch and fix ports like devel/libsoup (remove the second tar:xz). These are the four cases that matter: USES=foo foo:arg old meaning: USES=foo new meaning: USES=foo:arg USES=foo:arg foo old meaning: USES=foo:arg new meaning: USES=foo:arg USES=foo:arg1 foo:arg2 old meaning: USES=foo:arg1 new meaning: USES=foo:arg1,arg2 USES=foo:arg foo:arg old meaning: USES=foo:arg new meaning: USES=foo:arg,arg I think these changes are ok except for qmake, but you can change the USES+=qmake:_env in bsd.qt.mk into something like this: .if empty(USES:Mqmake) && empty(USES:Mqmake\:*) USES+=qmake:_env .endif
Comment 10 Hannes Hauswedell 2016-04-11 14:28:37 UTC
Any news on this? I wanted to specify compiler:cxx14-lang compiler:openmp but now I am forced to use USE_GCC (although llvm38 would be fine, too). Thanks for your help!
Comment 11 Hannes Hauswedell 2017-01-12 23:03:54 UTC
This has been open nearly two years now, although patches are attached. Any news? With a growing number of standards and optional features in c++, I expect this would affect more ports that still falsely claim to require GCC, although flags could be used instead...
Comment 12 Eitan Adler 2018-05-23 10:27:23 UTC
batch change of PRs untouched in 2018 marked "in progress" back to open.
Comment 13 Justin Hibbits 2018-06-28 16:53:09 UTC
I was just about to file this exact same bug. I can't build biology/canu on powerpc64 because it needs a compiler:c++11-lib option, but that's already taken with compiler:openmp.
Comment 14 Mathieu Arnold 2018-08-14 08:59:23 UTC
I think the patch to Mk/bsd.port.mk should be dropped. It is not required.