search for: cmake_sysroot

...ine the compiler, system type, architecture, sysroot, etc. It enables a simpler, and more versatile build script. With tip of the tree on llvm and sub-projects now, when I use a toolchain file, I'm finding I have to make edits to the config-ix.cmake files. The issue is related to re-defining CMAKE_SYSROOT and the use of; among others: set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -nodefaultlibs") When this flag is used in stand-alone cross-compiled builds (using toolchain file to set the CMAKE_SYSROOT), it causes all the subsequent flag checks to fail. I think leveraging an impl...

On 11 March 2015 at 13:06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > So that we can drop autotools, which currently requires anyone wanting > to change the build to install an old version of autoconf, among other > pains. Having two build systems is a way bigger pain than someone > having to install cmake. Can you explain why we need to upgrade CMake to drop

...ation<https://cmake.org/cmake/help/v3.14/manual/cmake-toolchains.7.html#cross-compiling-for-ios-tvos-or-watchos> The CMAKE_SYSTEM_NAME is the CMake-identifier of the target platform to build for.. The CMAKE_SYSTEM_PROCESSOR is the CMake-identifier of the target architecture to build for.. The CMAKE_SYSROOT is optional, and may be specified if a sysroot is available.. The CMAKE_STAGING_PREFIX is also optional. It may be used to specify a path on the host to install to. The CMAKE_INSTALL_PREFIX is always ... cmake.org ________________________________ From: opus <opus-bounces at xiph.org> on beh...

...requiring a certain version of cmake, that would be a good discussion to > have. Saying that there might be things and that they might help isn't going > to get us anywhere. ;] >From above in this thread: -------------------------------------------------- I should also point out that CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_TARGET (both CMake 3.0 features) would make fixing compiler-rt's CMake (Bugs 14109 & 21562) a lot easier. Both of those bugs are currently blockers to depreciating the autotools build system. ------------------------------------------------- But it does look...

...; >> Can you explain why we need to upgrade CMake to drop autotools? >> > > From above in this thread: > > --------------------------------------- > From above in this thread: > > -------------------------------------------------- > I should also point out that CMAKE_SYSROOT and > CMAKE_<LANG>_COMPILER_TARGET (both CMake 3.0 features) would make > fixing compiler-rt's CMake (Bugs 14109 & 21562) a lot easier. Both of > those bugs are currently blockers to depreciating the autotools build > system. > ------------------------------------------...

----- Original Message ----- > From: "Renato Golin" <renato.golin at linaro.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "jroelofs" <jonathan at codesourcery.com>, "Tobias Grosser" <tobias at grosser.es>, > "David Chisnall" <David.Chisnall at

...aaaaaaaaa%7C1%7C0%7C637224523564096059&sdata=s85t4wULfxV5mLOcheTvhV%2Bel%2BQd1uZlr5kF0z9WyCw%3D&reserved=0> The CMAKE_SYSTEM_NAME is the CMake-identifier of the target platform to build for.. The CMAKE_SYSTEM_PROCESSOR is the CMake-identifier of the target architecture to build for.. The CMAKE_SYSROOT is optional, and may be specified if a sysroot is available.. The CMAKE_STAGING_PREFIX is also optional. It may be used to specify a path on the host to install to. The CMAKE_INSTALL_PREFIX is always ... cmake.org<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcmake.org%2F&...

...//cmake.org/cmake/help/v3.14/manual/cmake-toolchains.7.html#cross-compiling-for-ios-tvos-or-watchos> > The CMAKE_SYSTEM_NAME is the CMake-identifier of the target platform to > build for.. The CMAKE_SYSTEM_PROCESSOR is the CMake-identifier of the > target architecture to build for.. The CMAKE_SYSROOT is optional, and may > be specified if a sysroot is available.. The CMAKE_STAGING_PREFIX is also > optional. It may be used to specify a path on the host to install to. The > CMAKE_INSTALL_PREFIX is always ... > cmake.org > > > ------------------------------ > *From:* opus &...

...* New ALIAS targets * CMAKE_CONFIGURATION_TYPES variable is defined in multi-config generators (we already use this) * XCODE_ATTRIBUTE_* might be nice for our Xcode users… * cmake_reset_check_state - would be handy for anyone doing development against changing target operating systems CMake 3.0 * CMAKE_SYSROOT * CMAKE_<LANG>_COMPILER_TARGET would be useful for cross-compiling Aside from this there are lots of fixes and changes around the export() and install(EXPORT) commands that should make cross-compiling better. Like I said, I actually don’t care that much about the move to 2.8.12.2, but I car...

...;ve all earned the "Bike Shed Master Badge" today. Let me re-list all the reasons why we should move on, then all the problems of doing so, so we can base our arguments on current facts. == Pro move == 1. Using OBJECT libraries (2.8.8) has massive improvement when linking on Windows 2. CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_TARGET (3.0) would help fix compiler-rt builds 3. Ninja "pool = console" would fix the timeout issues on slow builds, but it's not clear how CMake would do that by default 4. Windows and OSX users already build by hand anyway Item (1) was already solve...

> We don't require users to compile their own gcc. Are you saying it's > impossible to get pre-built CMake 2.8.12 and gcc 4.7 on either Mac or > Windows? And we wouldn't be requiring it for cmake. My point was that cmake is always easier to install: * From binaries: a bit easier, since they are provided in http://www.cmake.org/ * From source: way easier than gcc. Gosh, from

...this to become a big Windows > & OS X vs Linux discussion (sorry Chandler!). > > Parallel to all this I went out last night and started playing with trying > to use the new CMake features to make the compiler-rt build better. What I > found was disappointing. > > Turns out CMAKE_SYSROOT is (IMO) actually a pretty broken option. It only > controls the --sysroot compiler flag. Also, oddly enough the > CMAKE_OSX_SYSROOT flag (which I think is poorly named) controls -isysroot. > The core problem here is that neither of these options really provides a > portable interface f...

On Tue, Mar 10, 2015 at 8:47 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > However, everyone seems to think I'm advocating we never move the CMake > > version forward. That isn't what I'm saying at all. What I am saying is > that > > moving the CMake version forward has a cost. Not a huge insurmountable > cost, > > but non-zero

On 24.02.2015 17:45, Tobias Grosser wrote: > On 09.02.2015 20:12, Chris Bieneman wrote: >> It came up on another thread that our current minimum required CMake >> version 2.8.8, has some bugs that cause issues when building with MSVC >> + Ninja, and one potential solution was to raise the minimum required >> version of CMake. >> >> CMake 3.0 is now 6 months

> On Feb 24, 2015, at 11:13 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Feb 24, 2015, at 9:33 AM, Chris Bieneman <beanz at apple.com> wrote: >> >>> >>> On Feb 24, 2015, at 8:45 AM, Tobias Grosser <tobias at grosser.es> wrote: >>> >>> On 09.02.2015 20:12, Chris Bieneman wrote: >>>> It