Bug 160877

please reassign to ports

Comment 2 Mark Linimon 2011-09-21 22:01:48 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-ports-bugs

ports PR.

Comment 3 Brendan Fabeny 2011-09-22 11:27:40 UTC

Responsible Changed
From-To: freebsd-ports-bugs->bf

I'll take it.

    I'd like to know how you're building stuff with nanobsd, because I
had to go through quite a few tricks to get things to work (but it
works properly with nanobsd once you apply those tricks and I haven't
had to hack nanobsd -- yet).
    See: http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/nanobsd/common?r1=8092&r2=8193
as an example (but note some of the newer revisions too).
Thanks,
-Garrett

On 10/26/11, Garrett Cooper <yanegomi@gmail.com> wrote:
> The following reply was made to PR ports/160877; it has been noted by GNATS.
>
> From: Garrett Cooper <yanegomi@gmail.com>
> To: bug-followup@FreeBSD.org, r.neese@gmail.com
> Cc:
> Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
> Date: Wed, 26 Oct 2011 16:18:07 -0700
>
>      I'd like to know how you're building stuff with nanobsd, because I
>  had to go through quite a few tricks to get things to work (but it
>  works properly with nanobsd once you apply those tricks and I haven't
>  had to hack nanobsd -- yet).
>      See:
> http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/nanobsd/common?r1=8092&r2=8193
>  as an example (but note some of the newer revisions too).

Why are the FreeNAS scripts defining TARGET_ARCH when dealing with
ports/packages?  This variable shouldn't be set when building
packages, because it breaks many builds. The fact that this is done in
FreeNAS scripts and in some other examples posted on the web seems to
be setting a bad example for others:  there have been a slew of PRs
(see below, for a sample -- especially 158013) from people who are
mistakenly polluting their package build environment with this
variable, and then demanding that ad hoc fixes be implemented in
individual ports, which is a real pain.  We should not -- indeed,
cannot -- be cluttering up random ports with workarounds for every
unneeded variable that may be set by a user.  If TARGET_ARCH is
considered to be exceptional in some sense, because users are more
likely to set it in a mistaken analogy with cross-building in the base
system, or because it is used in nanobsd, and it is thought that we
need some active measures to prevent TARGET_ARCH pollution, then these
measures should be in a central Makefile, not scattered throughout the
Ports tree.

cf. PRs:

147853
151224
156607
157457
157479
157512
158013*
160877
160885
160888

Regards,

b.

On Oct 26, 2011, at 7:21 PM, b. f. wrote:

> On 10/26/11, Garrett Cooper <yanegomi@gmail.com> wrote:
>> The following reply was made to PR ports/160877; it has been noted by =
GNATS.
>>=20
>> From: Garrett Cooper <yanegomi@gmail.com>
>> To: bug-followup@FreeBSD.org, r.neese@gmail.com
>> Cc:
>> Subject: Re: ports/160877: port fix to build audio/cmt on nanobsd
>> Date: Wed, 26 Oct 2011 16:18:07 -0700
>>=20
>>     I'd like to know how you're building stuff with nanobsd, because =
I
>> had to go through quite a few tricks to get things to work (but it
>> works properly with nanobsd once you apply those tricks and I haven't
>> had to hack nanobsd -- yet).
>>     See:
>> =
http://freenas.svn.sourceforge.net/viewvc/freenas/trunk/nanobsd/common?r1=3D=
8092&r2=3D8193
>> as an example (but note some of the newer revisions too).
>=20
> Why are the FreeNAS scripts defining TARGET_ARCH when dealing with
> ports/packages?

We're defining it always inside of nanobsd when cross building.  We try =
to build everything with the same environment, but if there are certain =
things that are different between /usr/ports and /usr/src, then I can =
cope.

> This variable shouldn't be set when building
> packages, because it breaks many builds. The fact that this is done in
> FreeNAS scripts and in some other examples posted on the web seems to
> be setting a bad example for others:  there have been a slew of PRs
> (see below, for a sample -- especially 158013) from people who are
> mistakenly polluting their package build environment with this
> variable, and then demanding that ad hoc fixes be implemented in
> individual ports, which is a real pain.  We should not -- indeed,
> cannot -- be cluttering up random ports with workarounds for every
> unneeded variable that may be set by a user.  If TARGET_ARCH is
> considered to be exceptional in some sense, because users are more
> likely to set it in a mistaken analogy with cross-building in the base
> system, or because it is used in nanobsd, and it is thought that we
> need some active measures to prevent TARGET_ARCH pollution, then these
> measures should be in a central Makefile, not scattered throughout the
> Ports tree.

What's the right way to cross build ports?

Warner




> cf. PRs:
>=20
> 147853
> 151224
> 156607
> 157457
> 157479
> 157512
> 158013*
> 160877
> 160885
> 160888
>=20
> Regards,
>=20
> b.
>=20
>=20

On 10/26/11, Warner Losh <imp@bsdimp.com> wrote:
> The following reply was made to PR ports/160877; it has been noted by GNATS.
>
> From: Warner Losh <imp@bsdimp.com>

>
>  What's the right way to cross build ports?

As far as I know, we've never guaranteed that they could be
cross-built.  But some users have had success building large numbers
of packages for i386 in tinderboxes on amd64, for example.  For those
builds, the users usually specify ARCH, MACHINE_ARCH, UNAME_m,
UNAME_p, and occasionally CPUTYPE.  Probably a few people have
experience with powerpc64/powerpc32, etc., but we'd have to consult
the others.

b.

On Oct 26, 2011, at 10:01 PM, b. f. wrote:

> On 10/26/11, Warner Losh <imp@bsdimp.com> wrote:
>> The following reply was made to PR ports/160877; it has been noted by =
GNATS.
>>=20
>> From: Warner Losh <imp@bsdimp.com>
>=20
>>=20
>> What's the right way to cross build ports?
>=20
> As far as I know, we've never guaranteed that they could be
> cross-built.  But some users have had success building large numbers
> of packages for i386 in tinderboxes on amd64, for example.  For those
> builds, the users usually specify ARCH, MACHINE_ARCH, UNAME_m,
> UNAME_p, and occasionally CPUTYPE.  Probably a few people have
> experience with powerpc64/powerpc32, etc., but we'd have to consult
> the others.

FreeNAS builds lots of ports like that.  But all those kludges are just =
that: kludges.

In the past, I've hacked the ports system to honor TARGET_ARCH, et al =
and it isn't that hard to get 2 of the three classes of ports.  Trivial =
ports can be cross built with just pointing CC, et al, at the right =
toolchain (which can either be make buildworld or make xdev).  Ports =
that grok cross building will work if you've installed a toolchain with =
make xdev.  The third class is ports that try to implement cross =
building, but do it wrong.  There's no hope for those ports.

There's a number of ports that are in the third class that can be made =
to work with small tweaks to Makefiles in the tree.  They can't be done =
centrally because the nature of the tweaks are very port specific.

Warner=

On Wed, Oct 26, 2011 at 09:07:04PM -0600, Warner Losh wrote:
> What's the right way to cross build ports?

Often talked about, often desired, never solved.

Frankly I think you know more about it than anyone else :-/ and thus
would appreciate your advice.

mcl

On 10/27/11, Warner Losh <imp@bsdimp.com> wrote:

>  >> What's the right way to cross build ports?
...
>  > As far as I know, we've never guaranteed that they could be
>  > cross-built.  But some users have had success building large numbers
>  > of packages for i386 in tinderboxes on amd64, for example.  For those
>  > builds, the users usually specify ARCH, MACHINE_ARCH, UNAME_m,
>  > UNAME_p, and occasionally CPUTYPE.  Probably a few people have
>  > experience with powerpc64/powerpc32, etc., but we'd have to consult
>  > the others.
>
>  FreeNAS builds lots of ports like that.  But all those kludges are just =
>  that: kludges.

Yes.  We've been more intent on trying to keep the ports working for
native builds on a few common architectures.

...

>  There's a number of ports that are in the third class that can be made =
>  to work with small tweaks to Makefiles in the tree.  They can't be done =
>  centrally because the nature of the tweaks are very port specific.

I'm sure that many people would welcome an effort to make
cross-building easier, but until we have an organized, documented
effort underway (projects like FreeNAS might be able to help with
this, and we are still looking forward to simplifications from
Warner's alternative toolchain project), with a means of testing
changes, and can distinguish between what necessary changes can be
made centrally, rather than in many different individual ports, then I
suggest that we avoid these piecemeal patches in the main Ports tree
-- in particular, in this case.

b.

Comment 11 Brendan Fabeny 2011-11-19 10:47:12 UTC

State Changed
From-To: open->closed

duplicate of ports/158013