According to doc: Use either `--enable-openmp' or `--enable-threads', not both. Ebuild allows both use flags to be turn on (but in this case configures fftw with: --disable-threads --enable-openmp ). Reproducible: Always
Then, it isn't allowing you to enable both finally, no? Not sure what do you want exactly :(
Now it is possible to have both flags on, imho only one of them can be enabled at one time.
If you enable both the openmp and threads USE flags, the threads flag is ignored. This is pretty standard ebuild behavior. Assigning to maintainer for the final verdict.
right, internally openmp superseeds threads. From the user side this is something you want isn't it?
From a formal point of view if "openmp" is set then "threads" do nothing. Binaries all the same when "threads" is on or off. It would be argument for option: a) "openmp" blocks "threads" and vice versa In both cases (--enable-openmp or --enable-threads ) fftw makes threads libraries and links them to libpthread.so . It could be usefull for user to know about such linking. This leads me to proposal: b) "openmp" should force to "threads" to be on Meseems option "b)" would be more usefull than option "a)". (In reply to comment #3) > If you enable both the openmp and threads USE flags, the threads flag is > ignored. This is pretty standard ebuild behavior. I don't see many packages support openmp, it hard to talk about standard behavior. I don't think it's good when use flag is ignored, it can missleads user.
