Re: force a compiler install, or default the port to reduced features?

[Lawrence Velázquez]

> On Sep 26, 2016, at 4:11 PM, Ken Cunningham  
> wrote:
> 
> And of course I find out that the preferred variant (a nice MacOSX GUI) 
> doesn't build with the default installation on about the only system I didn't 
> test it on - a vanilla 10.6 system (my 10.6 systems are LibCxxOnOlderSystems 
> now, with clang-3.7). 
> 
> So my choice is to let it use the existing default compiler and build a 
> somewhat impaired but usable command-line only version, or force a compiler 
> install (clang-3.4 works, maybe 3.3, clang 3.7 would be best), and get the 
> really much better racing-stripes GUI version. The compiler would be 
> installed precompiled on a vanilla 10.6 system. (LibCxx... systems already 
> have clang-3.7, and so don't have this problem).
> 
> I'm tempted to force the compiler install, and if so it might as well be to 
> clang-3.7.
> 
> Is this the "MacPorts" way?

The usual approach is to blacklist compilers that *don't* work.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: buildpath conf variable

[René J . V . Bertin]

On Monday September 26 2016 12:59:17 Ken Cunningham wrote:

> At $0.50 (canadian) per GB, I put them in most of my systems -- even a 120GB 
> version in my Beige G3 running MacOS 9.2.2. Now that is something to see!

The figure is the same here, except they're Euros. The 1Tb disk in my MBP came 
in at about 0.07€/Gb. Not a factor 10 anymore, but close enough.

The cheap Linux notebook I offered myself a few months ago came with a Seagate 
SSHD. A bit more expensive that the Hitachi (so-called) 1Tb hybrid in my Mac, 
possibly not as reliable, but I have been pleased with its speed.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: depends_build port:doxygen and +universal (or +docs)

[René J . V . Bertin]

On Monday September 26 2016 05:00:44 Ryan Schmidt wrote:

> If you "sudo port install" some port that depends on doxygen, and you request 
> variants doxygen provides:
> 
> * If doxygen is not installed, doxygen will be installed with the those 
> variant.
> * If doxygen is already installed, it will not be reinstalled with those 
> variants.

The thing is that that's not what I'm seeing. Maybe depends_build is different 
in that aspect than depends_lib?

> > I don't know if doxygen itself installs any libraries or headers; if not, 
> > it should use
> > 
> > installs_libs no

> I think that's what it should do. It installs bin/doxygen and then stuff in 
> share.


It doesn't, but adding the statement to the doxygen portfile also doesn't do 
the trick for me. Of course I rebuilt and reinstalled doxygen. Still:
{{{
%>  port installed doxygen
The following ports are currently installed:
  doxygen @1.8.10_2+wizard (active)

%> port -v deps .dbus +x11+documentation (y|n)? no
Full Name: dbus @1.10.8_1+documentation+x11
Build Dependencies:   port:pkgconfig, port:autoconf, port:automake, 
port:libtool, port:doxygen
Library Dependencies: port:expat, port:xorg-libsm, port:xorg-libX11

%> port -nv configure dbus +x11+documentation
--->  Computing dependencies for dbus...
The following dependencies will be installed: 
 doxygen
 python27
Continue? [Y/n]: n
}}}

In the logfile, I see:

{{{
snip
:debug:main Searching for dependency: doxygen
:debug:main Found Dependency: receipt exists for doxygen
:debug:main Changing to port directory: 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/textproc/doxygen
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for configure.dir
:debug:main Re-registering default for build.dir
:debug:main Sourcing PortGroup cmake 1.0 from 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/cmake-1.0.tcl
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from 
/opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Requested variant +documentation is not provided by port doxygen.
:debug:main Requested variant +x11 is not provided by port doxygen.
:debug:main Executing variant universal provides universal
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback 
portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback 
portbuild::add_automatic_buildsystem_dependencies
snip
}}}

IOW, the only way I found to declare a build dependency that doesn't impose 
+universal is to make it conditional:

{{{
if {![file exists ${prefix}/bin/doxygen]} {
depends_build-append \
port:doxygen
}
}}}

that should do about exactly the same as a `depends_build-append 
path:bin/doxygen:doxygen`, except for the part where it wants to install (or 
reactivate) doxygen+universal when I install dbus+universal.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

force a compiler install, or default the port to reduced features?

[Ken Cunningham]

One of the ports I've been working on (hatari, an Atari ST emulator) was 
accepted for inclusion. Thank you! Hope everyone enjoys using it.

And of course I find out that the preferred variant (a nice MacOSX GUI) doesn't 
build with the default installation on about the only system I didn't test it 
on - a vanilla 10.6 system (my 10.6 systems are LibCxxOnOlderSystems now, with 
clang-3.7). 

So my choice is to let it use the existing default compiler and build a 
somewhat impaired but usable command-line only version, or force a compiler 
install (clang-3.4 works, maybe 3.3, clang 3.7 would be best), and get the 
really much better racing-stripes GUI version. The compiler would be installed 
precompiled on a vanilla 10.6 system. (LibCxx... systems already have 
clang-3.7, and so don't have this problem).

I'm tempted to force the compiler install, and if so it might as well be to 
clang-3.7.

Is this the "MacPorts" way?

Thanks,

ken

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: buildpath conf variable

[Ken Cunningham]

On 2016-09-26, at 1:07 AM, René J.V. Bertin wrote:

> Hi,
> 
> I know that more and more people (esp developers?) are using SSDs and that 
> for them fragmentation starts hitting only when it's the free space that's 
> really severely fragmented.


The SSD was the single most impressive speed bump for MacOSX I've seen in a 
very long time.

At $0.50 (canadian) per GB, I put them in most of my systems -- even a 120GB 
version in my Beige G3 running MacOS 9.2.2. Now that is something to see!

Ken



___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153120] trunk/dports/fuse/sshfs

[Clemens Lang]

Hi,

On Mon, Sep 26, 2016 at 11:23:17AM -0700, Dan Ports wrote:
> For me, the main benefit is that it's immediately obvious where the
> patch comes from, and, since it's github, how it relates to the
> release version. (In this case, it's a backported patch from an
> unreleased version.)

This is something we should track anyway, regardless of where a patch is
or whether it is copied. I've made it a habit to follow
  
http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations
in patchfiles for my port, i.e. include

  Upstream-Status: Backport [$commit-id]
or
  Upstream-Status: Submitted [$url-to-pull-request-or-mailing-list]
or
  Upstream-Status: Inappropriate [configuration]

I encourage others to do the same.

> Obviously, there are other ways to accomplish this, but this one seems
> as good as any...

-- 
Clemens
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153120] trunk/dports/fuse/sshfs

[Dan Ports]

On Mon, Sep 26, 2016 at 07:23:38PM +1000, Joshua Root wrote:
> I really don't see a problem with using patch_sites for any patches that are
> available for download somewhere stable. In fact it's even slightly
> preferable because it avoids the extra work of adding the file and adding a
> comment like you mentioned, plus it reduces the size of the ports tree.

For me, the main benefit is that it's immediately obvious where the
patch comes from, and, since it's github, how it relates to the release
version. (In this case, it's a backported patch from an unreleased
version.)

Obviously, there are other ways to accomplish this, but this one seems
as good as any...

Dan

-- 
Dan R. K. PortsUW CSEhttp://drkp.net/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: buildpath conf variable

[Lawrence Velázquez]

> On Sep 26, 2016, at 7:19 AM, René J.V. Bertin  wrote:
> 
>> On Monday September 26 2016 04:45:19 Ryan Schmidt wrote:
>> 
>> Most users use Macs with a single volume, so I don't think a patch
>> for this is of general interest.
> 
> Can't the same be said for portdbpath?

Yes. I don't know the rationale for this setting, but if it were
proposed today I would object to it as too niche.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: buildpath conf variable

[Brandon Allbery]

On Mon, Sep 26, 2016 at 5:45 AM, Ryan Schmidt 
wrote:

> I can't guarantee this won't mess something up, but I think you can
> already delete the /opt/local/var/macports/build directory and replace it a
> symlink to another volume


Works fine. Did that on my MacBook Air.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: buildpath conf variable

[René J . V . Bertin]

On Monday September 26 2016 04:45:19 Ryan Schmidt wrote:

> I can't guarantee this won't mess something up, but I think you can already 
> delete the /opt/local/var/macports/build directory and replace it a symlink 
> to another volume.

That's what I'm preparing my system to test, but I seem to recall I tried it 
once already an went back...

> Most users use Macs with a single volume, so I don't think a patch for this 
> is of general interest.

Can't the same be said for portdbpath? Even with a single partition you could 
have multiple virtual volumes, or a (bloody fast) SD card in the cardreader.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: [153120] trunk/dports/fuse/sshfs

[Ryan Schmidt]

> On Sep 24, 2016, at 8:57 PM, dpo...@macports.org wrote:
> 
> Revision
> 153120
> Author
> dpo...@macports.org
> Date
> 2016-09-24 18:57:45 -0700 (Sat, 24 Sep 2016)
> Log Message
> 
> sshfs: fix "GLib-CRITICAL **: g_slice_set_config: assertion failed" warning
> (#52347)
> 
> Modified Paths
> 
>   • trunk/dports/fuse/sshfs/Portfile
>   • trunk/dports/fuse/sshfs/files/patch-configure.ac.diff

> -checksums   rmd160  85425d3198f5c0d8ae0d5a456a37b6294744f7c2 \
> -sha256  
> 2cafba9ff65a3e97a7a9aba4a7b83e683b598ffdac317c802bb8d166b1c4715a
> +checksums   sshfs-2.8.tar.gz \
> +rmd160  85425d3198f5c0d8ae0d5a456a37b6294744f7c2 \
> +sha256  
> 2cafba9ff65a3e97a7a9aba4a7b83e683b598ffdac317c802bb8d166b1c4715a \
> +e5acfce8eda218d.patch \
> +rmd160  fac4b490bdb653270d7f8e27b4d86fb089605e46 \
> +sha256  
> 53b165353c944303d0839bbe1bf16c04eaaee2deca89ccff729b1974d14aa8cb \

> +# fix g_slice_set_config error (#52347)
> +patch_sites https://github.com/libfuse/sshfs/commit/
> 
> +patchfiles-append   e5acfce8eda218d.patch


We usually reserve the use of externally-hosted patchfiles for those that are 
large and/or maintained elsewhere (for example, the PHP Suhosin patch). But 
this is a one-line patch to the upstream sources, which means it will be in the 
next release, and this patchfile should have been copied into the port's files 
directory instead. You can add a comment to the top of the patchfile with the 
URL you got it from, for example:

https://trac.macports.org/browser/trunk/dports/audio/taglib-extras/files/patch-cmake-modules-FindTaglib.cmake.diff?rev=153168

No need to change it now since it's working, but keep it in mind for future 
commits.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

buildpath conf variable

[René J . V . Bertin]

Hi,

I know that more and more people (esp developers?) are using SSDs and that for 
them fragmentation starts hitting only when it's the free space that's really 
severely fragmented. I have no experience in that area, and do not currently 
have the budget to obtain that experience.

Either way, it seems to me that it might be an interesting idea to make it 
possible (easier) to put the build directory on a separate volume (interesting 
for anyone building a lot from source). This removes a big source of free space 
fragmentation (on disks where fragmentation is an issue), but in general helps 
keep ${prefix} cleaner. It can also help keeping log files more compact and 
thus more readable if a shorter base path is chosen.

Is this an idea that would stand a chance being considered for "base", IOW, 
should I file a wishlist ticket on trac?

In fact I have an untested hunch that at least for my own purposes it could be 
useful to have separate trees (and thus potentially separate volumes) for 
source.dir and build.dir/destroot.dir, where possible ... but I also have a 
hunch that would be more anyone could ask for :)

Cheers,
René
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev