Martin Storsjö <[email protected]> writes: > On Sat, 13 Oct 2012, Hendrik Leppkes wrote: > >> On Sat, Oct 13, 2012 at 8:14 PM, Måns Rullgård <[email protected]> wrote: >>> Hendrik Leppkes <[email protected]> writes: >>> >>>> On Sat, Oct 13, 2012 at 7:46 PM, Derek Buitenhuis >>>> <[email protected]> wrote: >>>>> On 13/10/2012 1:29 PM, Måns Rullgård wrote: >>>>>> I don't really like calling the OS msvc. That is the compiler. How >>>>>> about "windows"? >>>>> >>>>> By that logic, shouldn't we also call mingw32 "windows"? >>>>> >>>> >>>> Yeah, technically its the same OS, and the configuration how to create >>>> shared libraries doesn't belong in a OS section, but a toolchain >>>> section - but thats being done for like every OS, because in most >>>> cases there is an assumption that there is only one wide-spread >>>> compiler/linker for that target OS. >>> >>> The way (shared) libraries are built is usually dictated much more by >>> the OS than by the specific compiler. It is, after all, the OS that in >>> the end will be loading them. Windows is the odd one out here with at >>> least three totally different schemes in common use. >>> >>> If you look at the other ones, the settings are very much per OS and >>> hardly per compiler at all. Symbian is a prime example, building with >>> gcc yet needing a raft of special flags. >>> >>>> In any case, i would suggest going with something as simple as >>>> "windows" or "win32" to stick with microsofts short-form :p >>> >>> I'm fine with win32 as well. Is the 64-bit Windows also called win32? >>> >> >> Win64 is used sometimes when you want to stress the difference, but >> its the same OS in 64-bit, does it make sense to separate here? Maybe >> stick to "windows" and keep the 32/64 out of it to avoid confusion? > > Some of the target_os cases have * to match different settings, I can > set it to win*.
That sounds a bit greedy. Matching win32|win64 should be safe. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
