On 06/20/2012 05:28 AM, Allan McRae wrote:

This does not handle split packages that have different architectures.

Split packages use pkgbase rather than pkgname[@] as the name for the logfile, so even if you override arch from within a package function my patch should work. Could someone else take a look? -- Florian Pritz -- {flo,bluewind}@server-speed.net

On Wed, Jun 20, 2012 at 10:56 AM, Allan McRae wrote:

On 21/06/12 00:31, Florian Pritz wrote:

...

On 06/20/2012 05:28 AM, Allan McRae wrote:

...

This does not handle split packages that have different architectures.

Split packages use pkgbase rather than pkgname[@] as the name for the logfile, so even if you override arch from within a package function my patch should work.

Could someone else take a look?

On 21/06/12 00:31, Florian Pritz wrote:> On 06/20/2012 05:28 AM, Allan McRae wrote:

...

...

This does not handle split packages that have different architectures.

Split packages use pkgbase rather than pkgname[@] as the name for the logfile, so even if you override arch from within a package function my patch should work.

Could someone else take a look?

What should the log file names be for this PKGBUILD?

pkgname=('foo' 'bar') pkgver=1 pkgrel=1 arch=('i686' 'x86_64')

package_foo() {  : }

package_bar() {  arch=('any') }

What about for this one?

pkgname=('foo' 'bar') pkgver=1 pkgrel=1 arch=('any')

package_foo() {  : }

package_bar() {  arch=('i686' 'x86_64') }

Now...  I actually like the actual build arch listed in the log file name.   If I have an "arch=any" package that fails only on a certain architecture, it is handy to know what arch it was build on.  So I see the current behaviour as a feature and not a bug.

Allan

I'm the one who first reported this makepkg behaviour on the pacman IRC channel. My initial problem was simply that it wasn't the filename I would expect. As Allan said, having the actual CARCH of the system that a package was built on might be useful for debugging so I don't mind if we keep the current behaviour. In case we want to change it, I did tested the proposed patch. For unsplitted 'any' arch package it works well: foo-1-1-any-build.log foo-1-1-any-package.log For Allan's first example: As we are building both 'x86_64' and 'any' packages and both package share common build (and check) logs, using $CARCH makes sense here. foo-1-1-x86_64-build.log foo-1-1-x86_64-package_bar.log foo-1-1-x86_64-package_foo.log For Allan's second example: We're basically back to square one with the roles reversed. It would be better to use $CARCH like in the first example. foo-1-1-any-build.log foo-1-1-any-package_bar.log foo-1-1-any-package_foo.log In conclusion, if we decide to change the current behavior, the best way to to do it, IMHO, would be: - use logarch="any" for unsplitted 'any' arch package or splitted package containing only 'any' arch packages. - use logarch=$CARCH in all the other cases. Eric