svn commit: r404525 - head/lang/ghc

[Dmitry Marakasov]

* Mathieu Arnold (mat at FreeBSD.org) wrote:

> |> | Author: amdmi3
> |> | Date: Sat Dec 26 14:57:28 2015
> |> | New Revision: 404525
> |> | URL: https://svnweb.freebsd.org/changeset/ports/404525
> |> | 
> |> | Log:
> |> |   - Mark NO_CCACHE, fails to build with ccache enabled:
> |> |   
> |> |   ccache: error: Failed to create directory /nonexistent/.ccache/tmp:
> |> | Permission denied   
> |> 
> |> This should work if you don't build as a user.
> | 
> | It `should' work regardless of how the port is built.
> | 
> |> And while fixing ports to build as a user is a good thing, marking
> |> ports BROKEN when they build as root is not a good thing.
> | 
> | I haven't marked this port broken. NO_CCACHE just disables ccache.
> 
> Mmm, yes, sorry, tired. The thing is, you should not disable CCACHE if it
> does not work as a user, it's not fixing the problem. devel/spark has the
> same kind of problem, trying to get the HOME from /etc/password instead of
> from the environment variable HOME :
> 
> http://package19.nyi.freebsd.org/data/102amd64-default-build-as-user/404607/logs/errors/apache-spark-1.5.2.log

My point is that (as much as it's possible) the port should build
regardless of environment, plus I believe that pretty soon we will
be able to switch to user builds by default. I've assumed you had
the same goal in mind as not long ago you've fixed the most (if not
all) ports that still failed to build as user. I also think that
ccache support for couple of ports is not such a big loss compared
to consistent user builds support.

Actually we could stick NO_CCACHE under ${UID} != 0 condition here,
however I'm worried that if there are problems in user build, ccache
build may also work incorrectly, though there's no visible error.

Now, I've just realized that something fishy is definitelty going
on here - poudriere sets CCACHE_DIR directly, so it should not
depend on HOME in any way, unless the port overrides (which it
should never do) CCACHE_DIR or cleans environment completely (which
it probably shouldn't do either; scons does this unless specifically
teached not to for instance).

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru      http://amdmi3.ru