similar to: Upcoming configuration file changes

On 23 May 2016 7:36 a.m., "Sorin Srbu" <Sorin.Srbu at orgfarm.uu.se> wrote: > > > -----Original Message----- > > From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On > > Behalf Of Chuck Munro > > Sent: den 22 maj 2016 17:11 > > To: centos at centos.org > > Subject: Re: [CentOS] Upcoming OwnCloud changes > > >

Just a FYI folks ... I am running OwnCloud 9.0.2 on CentOS 6.7 and php-7.0 with no issues. I installed the Webtatic repo which has several versions of PHP available for CentOS 6 and 7. I then used the official OwnCloud ce:stable repo to add the cloud software. In a leap of faith, and because this CentOS VM doesn't run anything other than OwnCloud, I used the 'php70w' PHP repo

> -----Original Message----- > From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On > Behalf Of Chuck Munro > Sent: den 22 maj 2016 17:11 > To: centos at centos.org > Subject: Re: [CentOS] Upcoming OwnCloud changes > > > Just a FYI folks ... > > I am running OwnCloud 9.0.2 on CentOS 6.7 and php-7.0 with no issues. > > I installed

Maintenance of Asterisk 1.6.0 and 1.6.1 will move to security fixes only in approximately one month. There are bug fix releases scheduled to be released during the first half of May for both versions. After those releases, Asterisk 1.6.0 and 1.6.1 will only receive security fixes. The Asterisk development team recommends that all users of Asterisk 1.6.0 and 1.6.1 series move to the 1.6.2 series

Maintenance of Asterisk 1.6.0 and 1.6.1 will move to security fixes only in approximately one month. There are bug fix releases scheduled to be released during the first half of May for both versions. After those releases, Asterisk 1.6.0 and 1.6.1 will only receive security fixes. The Asterisk development team recommends that all users of Asterisk 1.6.0 and 1.6.1 series move to the 1.6.2 series

On 28 Oct 2011, at 02:11, Daniel Dunbar wrote: > TO BE CLEAR: I intend to introduce a hard dependency on requiring Python in > order to build LLVM. > > For the Makefiles, this is no worse than requiring Perl, so I don't think > there is much to argue with. I disagree there. Perl is pretty much guaranteed to be installed on any UNIXish system. Even FreeBSD, which has

Hello Anton. Anton Korobeynikov <anton at korobeynikov.info> writes: >> If having two build systems is a problem, just standardize on cmake. > Does cmake support cross-compilation? Can it cross-compile LLVM ? Yes: http://www.llvm.org/docs/CMake.html#cross The main difference is that you use a configuration file instead of passing arguments on the command line. Please note that

> The main difference is that you use a configuration file instead of > passing arguments on the command line. Please note that the > configuration file is for a toolset, not for a project (i.e. you don't > need to create one every time you want to cross-compile a new project > from Debian to Windows with MinGW.) Well, ok. How hard it will be to create something necessary for

Daniel Dunbar <daniel at zuster.org> writes: > My proposal makes it relatively easy for a motivated engineer to > generate "clean" Xcode projects for LLVM. "Relatively easy..." famous last words :-) And how is that different from fixing the cmake Xcode generator?

On Oct 28, 2011, at 2:16 PM, Óscar Fuentes wrote: > Eric Christopher <echristo at apple.com> > writes: > >> FWIW as "the other guy who works on the build system that isn't cmake" >> I'm all for this. I have no problem with a python dependency and ultimately >> replacing two build systems with a single well documented and more >>

> BTW, adding explicit library dependencies will make the parallel builds > worse, because you know when a dependency is missing (the build fails) > but you don't know when a dependency is superfluous. Computing the dependencies creates a point in the build that depends on all libraries and all tools depend on it. The explicit dependencies would have to be in a really bad state to

Rafael Ávila de Espíndola <rafael.espindola at gmail.com> writes: >> BTW, adding explicit library dependencies will make the parallel builds >> worse, because you know when a dependency is missing (the build fails) >> but you don't know when a dependency is superfluous. > > Computing the dependencies creates a point in the build that depends on > all

greened at obbligato.org (David A. Greene) writes: > Hmm...it's a build system, right? There's not much to add, really. > Build systems should be really simple. All they need is dependencies > and rules to build stuff. Oh, yes, sure, you're right. <g> [snip] > What sorts of features can you imagine we'd want to add? That's a question for Daniel. He is

Alek Paunov <alex at declera.com> writes: >> That said, if the information required for the build is going to be >> made explicit, maybe this isn't such a problem, as other tools can be >> written to parse it and run the build. > > Absolutely - once the generators are prototyped and tested in Python, if > current Perl (presence) > Python's, they can be

Joerg Sonnenberger <joerg at britannica.bec.de> writes: > As I said earlier in this thread: LLVM is nowhere big enough in terms > of subdirectories that recursive make is a significant contributor to > build time. But it is and many people have reported their experiences to that effect. One can't simply deny the experiences of many developers.

Nico Weber <thakis at chromium.org> writes: >>>> Furthermore, recursive make is necessary for automatic generation of >>>> header dependencies, among other things. The makefiles generated by >>>> cmake are "partially" recursive for that reason: >>> >>> Eh?  This is not true.  See for example: >>> >>>

Joachim Durchholz <jo at durchholz.org> writes: > On the reasons why make-based builds are slow, Peter Miller has some > insight to offer: > http://miller.emu.id.au/pmiller/books/rmch/ . > I'm not sure how widely recognized that paper is. Maybe it's widely > known and today's build times stem from other things than recursive make. The paper is widely

On Wed, Nov 02, 2011 at 12:29:33AM +0100, Óscar Fuentes wrote: > Joerg Sonnenberger > <joerg at britannica.bec.de> writes: > > > So I am maintaing Makefiles for NetBSD for LLVM as well. I know the > > FreeBSD guys do the same for them. > > Maybe it is not useful for the FreeBSD guys, but the makefiles generated > by cmake are compatible with BSD `make'

On Tue, Nov 01, 2011 at 06:27:35PM -0500, David A. Greene wrote: > Here is actual data comparing an empty LLVM build done recursively (the > LLVM build) and non-recursively (the Cray build). > > See this? > > 0inputs+0outputs (0major+671804minor)pagefaults 0swaps > > vs. this? > > 0inputs+0outputs (0major+184605minor)pagefaults 0swaps > > That's I/O.

Dear All, We have a new 32 core machine, so I ran some numbers. These results are for compiling all of LLVM and Clang in a Debug build from scratch. The first number is the -j argument to make, and the rest is the result of the bash builtin time command. 2: 1612.950u 161.293s 15:04.92 196.0% 0+0k 0+0io 0pf+0w 4: 1624.101u 164.121s 8:00.74 371.9% 0+0k 0+0io 0pf+0w 8: