Re: #55884: mandoc @1.14.3: not using the right compiler

[Ken Cunningham]

On 2018-03-03, at 1:14 PM, Jan Stary wrote:
> 
> What of I have two of those, with different Xcode on each?

That is undesirable for reproducible builds. 

Most users have the default Xcode version for a give system, as Apple flushes 
all the updates that way.

If users report broken builds and we recognize non-standard configurations, we 
encourage them to use the default version of Xcode for their system, and 
generally report that the default toolchain installation is the only supported 
configuration. 

Otherwise, chaos. 

> 
> Can you please indly point me to the place in MP base
> where the value of configure.cc get decided?
> 

/opt/local/libexec/macports/lib/port1.0/portconfigure.tcl

Re: #55884: mandoc @1.14.3: not using the right compiler

[Jan Stary]

> > > mandoc's ./configure sets CC to whatever make(1) thinks CC is:
> > > CC=`printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -`
> > > Why exactly is it "not the right compiler"?
> > 
> > As env -i clears the environment,
> > how is this supposed to work at all?
> > This does not respect CC in the environment, which is what MacPorts
> > usually does.
> > 
> > $ export CC=foo
> > $ printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -
> > cc
> 
> That's on purpose: compile mandoc with
> whatever the local make(1) thinks $(CC) is.
> 
>   # You can manually override the compiler to be used.
>   # But that's rarely useful because ./configure asks your make(1)
>   # which compiler to use, and that answer will hardly be wrong.
> 
> mandoc's ./configure does not take CC from the environment.

In fact, configure says

  # --- default settings -
  # Initialize all variables here,
  # such that nothing can leak in from the environment.

> It determines it as above. You can override it of course,
> by setting CC=... in configure.local

Re: #55884: mandoc @1.14.3: not using the right compiler

[Jan Stary]

On Feb 28 08:03:31, ken.cunningham.web...@gmail.com wrote:
> The basic principle is that a build of a port on any darwin_N system
> anywhere will be identical to every other build on that darwin version
> on all other machines.

Does that mean that MP will set the same configure.cc for mandoc
on e.g. every Darwin 17.4.0? What of I have two of those,
with different Xcode on each?

Can you please indly point me to the place in MP base
where the value of configure.cc get decided?

> To do that, but build environment (and the runtime environment)
> need to be fully pre-defined.

As long as it's possible to have different Xcode versions on one darwin_N,
in what sense can the build environment be "fully pre-defined"? For example,
https://trac.macports.org/wiki/UsingTheRightCompiler says:

 For example, with Xcode 4.2 and later, CC is set to
 "/usr/bin/clang" so that there is no ambiguity.

"/usr/bin/clang" will be a different compiler with Xcode 4.2
and with Xcode 4.N


> See here:  for more info,
> and why this is what we need. I hope you can come to accept
> some of these MacPorts policies

This makes sense, unlike what's being said at
https://trac.macports.org/wiki/UsingTheRightCompiler

Are these policies clearly described somewhere?


On Feb 28 10:20:56, ryandes...@macports.org wrote:
> >> I had my MacPorts configured to error out if `cc` is used
> >> using the method described at  UsingTheRightCompiler#testing.
> > 
> > Why would you do that?
> 
> To detect ports that do not use a specific compiler.
> MacPorts policy is that all ports shall use a specific compiler.

Is this policy described somewhere?

> > BTW, this is how configure.cc is described in the guide:
> > 
> >  configure.cc
> >Set CC compiler flags for selecting a C compiler.
> >Default: ???
> >Example:
> > 
> > "compiler flags for selecting a compiler"?
> 
> Rainer has now adjusted these descriptions in the guide.

https://guide.macports.org/chunked/reference.phases.html still says
"Set CC compiler flags for selecting a C compiler."


On Feb 28 17:36:38, rai...@macports.org wrote:
> On 2018-02-28 08:52, Jan Stary wrote:
> > The ticket is closed, so I will continue here.
> > 
> >>  Actually it's not specific to the universal variant. Rather, the problem
> >>  is that the port is not UsingTheRightCompiler.
> > 
> > mandoc's ./configure sets CC to whatever make(1) thinks CC is:
> > CC=`printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -`
> > Why exactly is it "not the right compiler"?
> 
> As env -i clears the environment,
> how is this supposed to work at all?
> This does not respect CC in the environment, which is what MacPorts
> usually does.
> 
> $ export CC=foo
> $ printf "all:\\n\\t@echo \\\$(CC)\\n" | env -i make -sf -
> cc

That's on purpose: compile mandoc with
whatever the local make(1) thinks $(CC) is.

  # You can manually override the compiler to be used.
  # But that's rarely useful because ./configure asks your make(1)
  # which compiler to use, and that answer will hardly be wrong.

mandoc's ./configure does not take CC from the environment.
It determines it as above. You can override it of course,
by setting CC=... in configure.local

That seems to be the issue here: MP _wants_to_ tell mandoc what compiler
to use, but setting CC in the environment does not do it. Hence the CC
dance that we have in the Portfile now. Is this understanding correct?


> > It's true that /usr/bin/cc is a symlink to some suitable default compiler.
> > So call that, thus calling a suitable default compiler, _by_default_.
> 
> You are already assuming that 'cc' is /usr/bin/cc. If anyone has a
> /opt/local/bin/cc, it might be a different compiler.

If it is actually a C compiler, it will compile mandoc just fine.
If it is instead a shell script that errors out with "you must not run
this as your compiler", then it will not of course.

> In general, we do not want to use what the user selected as their
> preferred compiler, but what MacPorts selected to compile this port.

Is this strict policy clearly described somewhere, including the
rationale? Not in https://trac.macports.org/wiki/UsingTheRightCompiler

> > Yes, there are ports that do need to call some particular compiler,
> > but it's those ports' job then to find and use that.

> >> I had my MacPorts configured to error out if `cc` is used
> >> using the method described at  UsingTheRightCompiler#testing.
> > 
> > Why would you do that?
> >
> > Mandoc is extremely portable. I have yet to see a UNIX system where
> > it does not build. Except here: of course it "breaks" if you explicitly
> > make it impossible to run 'cc', which is the right compiler.
> 
> This setup is a good idea for developers to catch ports that are not
> respecting the environment variables for compiler selection.

This seems to confirm that this is what's "wrong" with mandoc in this
respect - it does not listen to MP's CC setting and has to be told
explicitly.

> 

Re: Mirorring distfiles

[Mojca Miklavec]

On 2 March 2018 at 15:02, Ryan Schmidt wrote:
> On Mar 1, 2018, at 16:09, Mojca Miklavec wrote:
>
>> Yes. I still find it super painful that we did not manage to migrate
>> to libc++ over all those years due to a basically "trivial" issue.
>>
>> My suggestion would be to use one hacking session during the meeting
>> to implement a few lines of code that take care of renaming the
>> binaries + test whether users could switch to libc++ using migration
>> tool written by Umesh.
>
> Please also take a look at this related issue about having separate libc++ 
> and libstdc++ portindexes, and what name to use to differentiate them:
>
> https://trac.macports.org/ticket/55471
>
> It doesn't have to use the same naming scheme as the archives we distribute, 
> but it could, so it could relate.

I wrote some comments to that ticket.

Mojca