Hi,
On 10-03-18, Antonio Rojas via arch-dev-public wrote:
> Currently most of our packages which use the cmake build system are built
> with -DCMAKE_BUILD_TYPE=Release. This provides a reasonable (according to
> upstream) set of C(XX)FLAGS defaults which are appended to and override our
>
On 14/03/18 04:19, Bartłomiej Piotrowski via arch-dev-public wrote:
> On 2018-03-13 14:40, Allan McRae via arch-dev-public wrote:
>> On 13/03/18 21:22, Jan Alexander Steffens via arch-dev-public wrote:
>>> For that matter, I'm all for putting an arch-configure helper into our
>>> autoconf package.
On 2018-03-13 15:32, Eli Schwartz via arch-dev-public wrote:
> This wrapper changes depending on which version of meson you have installed.
The wrapper is part of the package that changes.
> The fact that autoconf has weird bugs like needing to set localstatedir
> and sysconfdir to their
On 2018-03-13 14:40, Allan McRae via arch-dev-public wrote:
> On 13/03/18 21:22, Jan Alexander Steffens via arch-dev-public wrote:
>> For that matter, I'm all for putting an arch-configure helper into our
>> autoconf package.
>
> Don't muck around with vanilla packages. Put it in another package
On 03/13/2018 07:22 AM, Jan Alexander Steffens wrote:
> It's not magical. This doesn't even compare to dpkg-buildpackage's hooks
> and buildsystem handling, which changes behavior drastically based on
> what's installed and what the source tree looks like.
>
> arch-meson is just a wrapper
On 13/03/18 21:22, Jan Alexander Steffens via arch-dev-public wrote:
> For that matter, I'm all for putting an arch-configure helper into our
> autoconf package.
Don't muck around with vanilla packages. Put it in another package
(devtools).
A
On March 13, 2018 2:07:31 PM GMT+01:00, Bruno Pagani via arch-dev-public
wrote:
>Le 13/03/2018 à 13:42, Antonio Rojas via arch-dev-public a écrit :
>
>> El martes, 13 de marzo de 2018 11:23:07 (CET) Bruno Pagani via
>arch-dev-public escribió:
>>> Some projects
Le 13/03/2018 à 13:42, Antonio Rojas via arch-dev-public a écrit :
> El martes, 13 de marzo de 2018 11:23:07 (CET) Bruno Pagani via
> arch-dev-public escribió:
>> Some projects seems to default to Debug instead of None… So should we
>> specify a BUILD_TYPE of None instead of Release?
>>
> Not
El martes, 13 de marzo de 2018 11:23:07 (CET) Bruno Pagani via arch-dev-public
escribió:
> Some projects seems to default to Debug instead of None… So should we
> specify a BUILD_TYPE of None instead of Release?
>
Not sure if it's a good idea to systematically override the build type when it
On Sun, Mar 11, 2018 at 1:43 AM Eli Schwartz via arch-dev-public <
arch-dev-public@archlinux.org> wrote:
> While we are at it, someone has seen fit to create some arbitrary meson
> wrapper called "arch-meson" (note we have never shipped an arch-cmake
> nor an arch-configure, nor an arch-setup-py
Le 11/03/2018 à 10:00, Antonio Rojas via arch-dev-public a écrit :
> El domingo, 11 de marzo de 2018 1:44:07 (CET) Eli Schwartz via
> arch-dev-public escribió:
>> This theoretically sounds like a fantastic idea, but I'm not really sure
>> what CMake's deal with build flags are in the first
El domingo, 11 de marzo de 2018 21:58:16 (CET) Eli Schwartz via arch-dev-public
escribió:
> I know repository PKGBUILDs are typically built in a clean chroot, so
> cached builds make no difference there, but then neither do unquoted
> srcdir/pkgdir. It is still not helpful to people who e.g.
On 03/11/2018 05:00 AM, Antonio Rojas via arch-dev-public wrote:
> This is very poorly documented, so you have to dig into the cmake
> code to figure it out. The default build type is None, which means
> CMAKE_C(XX)_FLAGS is used (see
> /usr/share/cmake-3.10/Modules/CMakeCInformation.cmake:117),
El domingo, 11 de marzo de 2018 19:11:13 (CET) Bartłomiej Piotrowski via
arch-dev-public escribió:
> Sounds good. I'm also surprised that it's how it works, honestly. Are
> LDFLAGS taken into account regardless of CMAKE_BUILD_TYPE? Will there a
> to do list to track the progress?
>
Yes, linker
On 2018-03-10 11:34, Antonio Rojas via arch-dev-public wrote:
> Hi,
> Currently most of our packages which use the cmake build system are built
> with -DCMAKE_BUILD_TYPE=Release. This provides a reasonable (according to
> upstream) set of C(XX)FLAGS defaults which are appended to and override
El domingo, 11 de marzo de 2018 1:44:07 (CET) Eli Schwartz via arch-dev-public
escribió:
>
> This theoretically sounds like a fantastic idea, but I'm not really sure
> what CMake's deal with build flags are in the first place. What is the
> default build type, and does CMake even look at build
El sábado, 10 de marzo de 2018 14:34:16 (CET) Bruno Pagani via arch-dev-public
escribió:
> As long as you accept exceptions to this (I have scientific stuff in
> mind, like NetCDF — currently not built with CMake but will be in next
> release), I’m fine with this.
This is just about stopping
On 03/10/2018 05:34 AM, Antonio Rojas via arch-dev-public wrote:
> Hi, Currently most of our packages which use the cmake build system
> are built with -DCMAKE_BUILD_TYPE=Release. This provides a reasonable
> (according to upstream) set of C(XX)FLAGS defaults which are appended
> to and override
Le 10/03/2018 à 11:34, Antonio Rojas via arch-dev-public a écrit :
> Hi,
> Currently most of our packages which use the cmake build system are built
> with -DCMAKE_BUILD_TYPE=Release. This provides a reasonable (according to
> upstream) set of C(XX)FLAGS defaults which are appended to and
Hi,
Currently most of our packages which use the cmake build system are built with
-DCMAKE_BUILD_TYPE=Release. This provides a reasonable (according to upstream)
set of C(XX)FLAGS defaults which are appended to and override our default
C(XX)FLAGS. So, for instance, our cmake packages are being
20 matches
Mail list logo