Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Bartłomiej Piotrowski via arch-dev-public]

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 defaults minus the /usr prefix, is an autoconf
> bug. Maybe we could work on having meson not require setting bizarre
> options just to get sane defaults?

Neither is a bug. It's just a convenience script. Do you propose to work
on upstreaming defaults that make sense for Arch, but not necessarily
for what other distributions do or aim for?

> (Setting the prefix automatically propagates to everything specified
> with relative paths, which is most things, and libexecdir and sbindir
> could just specify a *different* relative path.)

(Which is completely unrelated to our use case, even if you put this
between parentheses.)

> So other languages, which completely disregard our CFLAGS but which
> meson itself has magic wrappers for... and the solution is to add a
> magic script to use in the PKGBUILD which does not respect makepkg.conf
> but can add debug symbols only loosely related to what we were trying to
> get? A script which arbitrarily adds debug symbols to packages that were
> rebuilt with OPTIONS=(!debug) by users who wanted to make local
> modifications?

Other languages ignore CFLAGS (hint: these are CFLAGS after all) anyway.
Users wanting to make local modifications were always on their own.

> since apparently meson is so perfect we should do literally everything
> directly in meson.

A cheap hyperbole. Obviously unnecessary if you want to be taken seriously.

> Or we could at least make a *proper* wrapper which can talk to makepkg
> and determine if debug info is wanted.

Patches welcome. Would be more productive use of your time than making a
storm in the glass of water here.

Bartłomiej

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Bartłomiej Piotrowski via arch-dev-public]

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
> (devtools).
> 
> A
> 

Makes no sense unless devtools become part of base-devel. It's hardly
any meddling as it doesn't hinder possibility to use default configure
script or meson binary.

Bartłomiej

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Eli Schwartz via arch-dev-public]

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 providing some defaults. You don't use the
> wrapper, you don't get the defaults.

"I object on principle to ever using the wrapper" -- then why does the
wrapper exist if we don't use it because we don't have to?

This wrapper changes depending on which version of meson you have installed.

> For that matter, I'm all for putting an arch-configure helper into our
> autoconf package. I've had all kinds of issues because builds forgot to
> set or mishandled some installation directory option from autoconf's
> general set. We should avoid having to repeat the same options over and
> over.

The fact that autoconf has weird bugs like needing to set localstatedir
and sysconfdir to their defaults minus the /usr prefix, is an autoconf
bug. Maybe we could work on having meson not require setting bizarre
options just to get sane defaults?

And arch-meson contains at least seven options that simply repeat the
defaults shown by running `meson ..; meson configure`.

(Setting the prefix automatically propagates to everything specified
with relative paths, which is most things, and libexecdir and sbindir
could just specify a *different* relative path.)

> I did not use plain because meson handles languages other than C and
> C++. Our FLAGS override the buildtype arguments anyway. We get the best
> of both worlds.

So other languages, which completely disregard our CFLAGS but which
meson itself has magic wrappers for... and the solution is to add a
magic script to use in the PKGBUILD which does not respect makepkg.conf
but can add debug symbols only loosely related to what we were trying to
get? A script which arbitrarily adds debug symbols to packages that were
rebuilt with OPTIONS=(!debug) by users who wanted to make local
modifications?

Maybe the solution is to get support for these languages to respect our
FLAGS regardless of whether the build system is implemented in meson. Or
I guess we could just replace our packaging system with meson so we can
consistently get debug info for nonconformant languages... since
apparently meson is so perfect we should do literally everything
directly in meson.

Or we could at least make a *proper* wrapper which can talk to makepkg
and determine if debug info is wanted.

This is dead simple, as libmakepkg allows creating bash functions that
run in makepkg itself and can talk to check_option()
It is also even more magical, because then there isn't even an obvious
executable file to look at...

Another option would be to look at CFLAGS (which are exported) and
enable debug iff "-g" is present. (Maybe meson could do this and
translate that to vala or rust or java or whatever flags, since it is
trying to provide seamless support for this everywhere...)

> We can move arch-meson's buildtype to debugoptimized as soon as we start
> building debug packages.

So then if someone checks out our PKGBUILDs and tries to build non-debug
versions, our FLAGS override and erase the buildtype resulting in a
plain old release build?

Because no, appending our FLAGS to the buildtype FLAGS is *not* the same
as overriding them. That's just adding more FLAGS and praying that every
buildtype FLAG is contra-indicated by an opposing makepkg.conf FLAG.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Allan McRae via arch-dev-public]

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

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Levente Polyak via arch-dev-public]

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 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 has been explicitely set by upstream. Some projects may be
>doing so for good reasons. Although explicitely setting it to Debug in
>a release tarball seems odd, do you have any example of such a project?
>
>
>The one I had in mind:
>https://github.com/Unidata/netcdf-c/blob/master/CMakeLists.txt#L122
>
>Release tarball is the same, they don’t change anything w.r.t. CMake in
>release tarball. Maybe it’s just one project and all other Arch Linux
>packages are not affected, but dropping BUILD_TYPE automatically at
>repo
>scale does not seems a good idea. I would prefer a todo list with
>instructions on checking what BUILD_TYPE and more importantly FLAGS
>where actually used by the build, even if I know you would rather have
>avoided one.


I think a TODO and checking flags would be a good idea, I also encountered 
similar things and even somehow ignoring flags fully but provide custom 
switches to set them.
If we touch this on a distro scale anyway, now would be a good time to ensure 
our distro FLAGS are indeed set for cmake stuff as we expect. Obviously there 
are weird things going on in some of them :p

Cheers,
Levente 

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Bruno Pagani via arch-dev-public]

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 sure if it's a good idea to systematically override the build type when 
> it has been explicitely set by upstream. Some projects may be doing so for 
> good reasons. Although explicitely setting it to Debug in a release tarball 
> seems odd, do you have any example of such a project? 

The one I had in mind:
https://github.com/Unidata/netcdf-c/blob/master/CMakeLists.txt#L122

Release tarball is the same, they don’t change anything w.r.t. CMake in
release tarball. Maybe it’s just one project and all other Arch Linux
packages are not affected, but dropping BUILD_TYPE automatically at repo
scale does not seems a good idea. I would prefer a todo list with
instructions on checking what BUILD_TYPE and more importantly FLAGS
where actually used by the build, even if I know you would rather have
avoided one.



signature.asc
Description: OpenPGP digital signature

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Antonio Rojas via arch-dev-public]

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 
has been explicitely set by upstream. Some projects may be doing so for good 
reasons. Although explicitely setting it to Debug in a release tarball seems 
odd, do you have any example of such a project? 

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Jan Alexander Steffens via arch-dev-public]

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 nor even an arch-make etc.),
> which aside for being somewhat magical also most certainly sets
> --buildtype release
>
> I distinctly remember this being something we do not want to support in
> makepkg due to us being fundamentally opposed to the end result where
> e.g. Debian packaging has magic in every which direction and you have to
> have a degree in Debian packaging plus go spelunking through addons
> provided by six or seven packages just to figure out how the actual
> build system for packages is being configured and run.
>

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 providing some defaults. You don't use the
wrapper, you don't get the defaults.

For that matter, I'm all for putting an arch-configure helper into our
autoconf package. I've had all kinds of issues because builds forgot to set
or mishandled some installation directory option from autoconf's general
set. We should avoid having to repeat the same options over and over.

I *know* that meson's buildtype=plain does the sane thing and delegates
> to the environment *FLAGS (or rather, the makepkg.conf *FLAGS and
> OPTIONS=(debug) if specified).
>

I did not use plain because meson handles languages other than C and C++.
Our FLAGS override the buildtype arguments anyway. We get the best of both
worlds.

We can move arch-meson's buildtype to debugoptimized as soon as we start
building debug packages.

Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake

[Bruno Pagani via arch-dev-public]

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 place. What is the
>> default build type, and does CMake even look at build flags from the
>> environment at all (at least in a sane manner)?
> 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), 
> whose value is taken from the environment C(XX)FLAGS (see 
> /usr/share/cmake-3.10/Modules/CMakeCXXInformation.cmake:198). So yes, not 
> setting CMAKE_BUILD_TYPE will simply use the build flags from C(XX)FLAGS. If 
> you want to test yourself, run cmake with the -LAH flag and check the output 
> for CMAKE_C(XX)_FLAGS.

Some projects seems to default to Debug instead of None… So should we
specify a BUILD_TYPE of None instead of Release?



signature.asc
Description: OpenPGP digital signature