Re: vnc

2018-07-25 Thread James Linder



> On 25 Jul 2018, at 8:00 pm, macports-users-requ...@lists.macports.org wrote:
> 
>> What exactly is your question ? The macPorts build of cotvnc is 64-bit and 
>> no warnings are offered running it. 
> 
> Agreed. I use cotvnc all the time and I've seen no problems with it on High 
> Sierra so far. Actually I use the cotvnc-devel port, to get the latest 
> development version.

My question was exactly what Ryan answered. Thanks Ryan. I installed and 
everything is perfect.

James

Re: verbose builds

2018-07-25 Thread Ryan Schmidt



On Jul 25, 2018, at 05:32, Rainer Müller wrote:

>> Would it be useful if port(1) had --disable-silent-rules
>> among configure.args by default? Or at least with port -vs?
>> Not having the actual commands renders the main.log a bit useless.
> 
> Yes, --disable-silent-rules should be used whenever possible. However,
> only configure scripts using automake will provide that option. Other
> configure scripts might also fail when unknown options are passed on the
> command line. Therefore I do not think it is not possible to make it a
> default.

I agree with Rainer that adding it to the default configure args now could 
break a lot of ports. If we had had it there from the beginning, ports that 
aren't compatible with it would already be removing it, but we didn't, and I 
don't want to break those ports now and spend the next few years finding and 
fixing them. If ports were already indicating via some variable that they use 
automake, we could add the flag only for those ports, but no such indication 
exists. So I think each port has to be responsible for ensuring a verbose build 
occurs, by whatever means is appropriate for that port. For automake ports, we 
usually add --disable-silent-rules to configure.args but one could add V=1 to 
build.args instead; other build systems may honor one or both of those methods 
too, or they may have other ways of achieving it (the cmake portgroup takes 
care of cmake's unique way of doing it, for example), or it may requires 
patches to the build system.

The reason why we didn't have that flag in the default configure args from the 
beginning is that the flag didn't used to exist; automake used to always use 
verbose rules. Then later (in automake 1.11), the option to use silent rules 
was introduced.

https://autotools.io/automake/silent.html

Then later, silent rules were made the default. We still want them disabled for 
MacPorts though, so that main.log files that users attach to bug reports 
contain useful information, so as projects' build systems are rebuilt with 
newer versions of autotools, a flag to disable the silent rules has to be added 
to those ports.

If we did want to add the flag by default, we would not want to put it in 
configure.args, because the purpose of configure.args is to be set by 
portfiles, and tons of them do; if we provided a default value for it in base, 
most ports would override it. We could put it in configure.pre_args instead, 
along with --prefix=${prefix}. Those ports that override configure.pre_args 
because they don't support --prefix=${prefix} probably don't support 
--disable-silent-rules either.

After writing the above, it occurs to me that adding V=1 to build.pre_args or 
build.post_args by default might be a solution. Unlike configure scripts, some 
of which complain about unknown flags being used, make isn't going to complain 
about unknown variables being set. There is of course still a possibility that 
some Makefiles may use a variable called V for some other purpose and that by 
overriding it to be 1 we might break those Makefiles. But my guess is that 
setting V=1 by default would break far fewer ports than using 
--disable-silent-rules by default. There are already 73 portfiles that set V=1 
manually, though there are a couple that set it to different values: cmus sets 
V=2, and lua51 sets V to a version number. And of course we have no idea how 
many ports' Makefiles internally use a variable called V that the Portfiles 
aren't currently setting.



Re: verbose builds

2018-07-25 Thread Rainer Müller
On 2018-07-25 07:21, Jan Stary wrote:
> In a recent thread, I came over the folowing:
> 
> On Jul 24 09:26:18, h...@stare.cz wrote:
>> On Jul 23 15:51:49, michae...@macports.org wrote:
>>> Looks like the link command is missing LAPACK or the equivalent (e.g. 
>>> maybe: Atlas, OpenBLAS, Eigen), but since the log doesn't include the 
>>> actual link command I can't say for certain. Maybe add some verbosity to 
>>> the build stage to show the actual link command? - MLD
>>
>> How do I do that on port(1) level?
>> Or do I need to tweak the actual Portfile with
>> something like --disable-silent-rules?
> 
> On Jul 24 11:17:18, michae...@macports.org wrote:
>> This would be a Portfile change, adding in the flag you mention.
>> ---enable-static
>> +--enable-static \
>> +--disable-silent-rules
> 
> Would it be useful if port(1) had --disable-silent-rules
> among configure.args by default? Or at least with port -vs?
> Not having the actual commands renders the main.log a bit useless.

Yes, --disable-silent-rules should be used whenever possible. However,
only configure scripts using automake will provide that option. Other
configure scripts might also fail when unknown options are passed on the
command line. Therefore I do not think it is not possible to make it a
default.

The -v flag should not change the build process. It only changes what is
displayed right on the terminal, while the log file will always contain
messages of all log levels. Use 'port log' [1] to view/filter the log
output after a failed build attempt.

Rainer

[1] https://man.macports.org/port-log.1.html