Re: [50191] trunk/dports/php/php5-eaccelerator/Portfile

On Apr 27, 2009, at 09:29, alaka...@macports.org wrote: Revision: 50191 http://trac.macports.org/changeset/50191 Author: alaka...@macports.org Date: 2009-04-27 07:29:29 -0700 (Mon, 27 Apr 2009) Log Message: --- Migrate php5-eaccelerator to the php5extension PortGroup Di

Re: lint version hardcode

On Apr 29, 2009, at 18:27, Rainer Müller wrote: Can't we just make it accept any ${portgroup}.setup? As of r50375 lint will ignore any lines starting with "^[a-z0-9]+\.setup". For the name this is the same regex used to verify a PortGroup line. This should be sufficient as *.setup is usual

Re: [50222] trunk/dports/graphics

Darren Weber wrote: > Does configure.optflags apply to CMAKE? I don't think so. Does not look like it does. I am not sure if this would be applicable and how it would be done. > While I agree that debugging during software development is better > without optimization, the real compromise here is

Re: [50222] trunk/dports/graphics

On Wed, Apr 29, 2009 at 3:40 PM, Rainer Müller wrote: > Darren Weber wrote: > > > > Oh, also vtk-devel is using a different build type, > > > > -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo > > > > This is consistent with GNU distributions that use -O2 -g to provide > > some degree of optimization and

Re: lint version hardcode

Ryan Schmidt wrote: > Ok, I added php5peclextension.setup in r50230. I didn't realize we > had this list of portgroups in portlint. This was added by me as I implemented the hardcoded version check based on existing PortGroups. So it is very new :-) > Can't we just make it accept > any ${portg

Re: [50222] trunk/dports/graphics

Darren Weber wrote: > > Oh, also vtk-devel is using a different build type, > > -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo > > This is consistent with GNU distributions that use -O2 -g to provide > some degree of optimization and the capacity to attach to and debug > running processes, examine cor

Re: xinstall glob question

Darren Weber wrote: > The {!} syntax is supposed to NOT that file name . I > have a directory of binary executables among a lot of .dylib files and I > want to exclude all the .dylib files from the glob. Tcl's glob is unable to invert a pattern. As you say, {!...} is not going to work. Some exam

Re: xinstall glob question

Pretty much, yes. I would also argue that (A) is clearer and easier to read, to say nothing of more efficient. There are a number of processes being spawned in (B) - one for the sh(1) to run the for loop, another sh(1) to execute the find(1) in backticks, another for the find(1) itself, t

Re: [50222] trunk/dports/graphics

Oh, also vtk-devel is using a different build type, -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo This is consistent with GNU distributions that use -O2 -g to provide some degree of optimization and the capacity to attach to and debug running processes, examine core dumps, etc. Best, Darren PS, The

Re: [50222] trunk/dports/graphics

FYI, these are my current commens in the vtk-devel port (my local repo only at this point), with regard to cmake RPATH config for macports build and install: # Notes on RPATH settings for the shared dylib build and install: # # CMake book, Appendix A, p 234: "CMAKE_SKIP_BUILD_RPATH: Do not include

Re: [50222] trunk/dports/graphics

On Tue, Apr 28, 2009 at 4:30 AM, Ryan Schmidt wrote: > On Apr 27, 2009, at 19:48, Darren Weber wrote: > > On Mon, Apr 27, 2009 at 5:01 PM, Ryan Schmidt wrote: >> >> Since this port uses cmake, have you considered using the cmake portgroup >>> to simplify it? >>> >> >> No, I didn't know such a po

Re: qt4-x11 and x11prefix

Jeremy Huddleston writes: > > qt4-x11's qmake is causing built applications to use /usr/X11 instead > of /opt/local for X11... This has caused some problems here, and I'm > sure others might see it too: > > ... > > So to summarize, the qt libs themselves are linked against /opt/local/ > l

Re: +system_x11 to bite the dust

Jeremy Huddleston writes: > > So, the MacPorts-provided X11 libs should be regression free over what > is installed in any x11prefix. The hardware-rendering libGL was the > last nail, and that's been fairly stable for the past 1-2 months. > > Can we successfully nuke the backwards-compatib

Re: +system_x11 to bite the dust

Jeremy Huddleston wrote: I think ${x11prefix} was mostly to avoid hardcoding /usr/X11R6 (or /usr/X11), but I gather you will be replacing it with $ {prefix} now ? (It was /usr/local on FreeBSD, but that doesn't really matter) No, I won't be replacing it with anything. It will be purged.

Re: +system_x11 to bite the dust

Jeremy Huddleston wrote: On Apr 29, 2009, at 12:41, David Evans wrote: I agree that this would be a move toward simplification, but the interest in universal builds makes me think that a number of people are using MacPorts to build applications to be distributed in binary form to various targ

Re: +system_x11 to bite the dust

On Apr 29, 2009, at 12:43, Anders F Björklund wrote: After this is done, I'm going to go through and start removing all the x11prefix references and workarounds in various ports. If you are maintainer on a !openmaintainer port that has reference to $ {x11prefix}, speak now, or I consider

Re: +system_x11 to bite the dust

On Apr 29, 2009, at 12:41, David Evans wrote: I agree that this would be a move toward simplification, but the interest in universal builds makes me think that a number of people are using MacPorts to build applications to be distributed in binary form to various target architectures. It w

Re: xinstall glob question

The {!} syntax is supposed to NOT that file name . I have a directory of binary executables among a lot of .dylib files and I want to exclude all the .dylib files from the glob. The system command is working, so I'll go ahead with that. Thanks, Darren On Wed, Apr 29, 2009 at 11:42 AM, Jeremy L

Re: +system_x11 to bite the dust

Jeremy Huddleston wrote: Can we successfully nuke the backwards-compatible system_x11 variant now? If any cares to answer "no," then you also need to explain why, so I can make sure to address your concerns before pulling the plug. "no, I like not using MP's X11 libs" is not a valid reas

Re: hamcrest-core and backing out changes

nox wrote: Le 28 avr. 09 à 23:21, Blair Zajac a écrit : nox wrote: Le 28 avr. 09 à 19:04, Blair Zajac a écrit : Hi, Regarding hamcrest-core r50259 Revert r50223, this port is called hamcrest-core and thus should install only hamcrest-core, please create an hamcrest-library port if you

Re: +system_x11 to bite the dust

Jeremy Huddleston wrote: So, the MacPorts-provided X11 libs should be regression free over what is installed in any x11prefix. The hardware-rendering libGL was the last nail, and that's been fairly stable for the past 1-2 months. Can we successfully nuke the backwards-compatible system_x11 va

Re: hamcrest-core and backing out changes

nox wrote: Le 29 avr. 09 à 10:11, nox a écrit : Le 28 avr. 09 à 23:21, Blair Zajac a écrit : nox wrote: Le 28 avr. 09 à 19:04, Blair Zajac a écrit : Then, we'll need to delete hamcrest-core. Separate ports look better to me. hamcrest-library created in r50332. Sweet, thanks, th

Re: +system_x11 to bite the dust

On Apr 29, 2009, at 14:24, Jeremy Huddleston wrote: So, the MacPorts-provided X11 libs should be regression free over what is installed in any x11prefix. The hardware-rendering libGL was the last nail, and that's been fairly stable for the past 1-2 months. Can we successfully nuke the ba

+system_x11 to bite the dust

So, the MacPorts-provided X11 libs should be regression free over what is installed in any x11prefix. The hardware-rendering libGL was the last nail, and that's been fairly stable for the past 1-2 months. Can we successfully nuke the backwards-compatible system_x11 variant now? If any car

Re: [50352] trunk/dports

On Apr 29, 2009, at 13:45, David Evans wrote: While you're reconsidering categories, how about moving pango and gtk2 to devel from x11? They're not just for X11 anymore. ;-) Sounds like a good idea to me. Any objection, Anthony? ___ macports-dev

Re: [50352] trunk/dports

ryandes...@macports.org wrote: Revision 50352 Author ryandes...@macports.org Date 2009-04-29 10:38:23 -0700 (Wed, 29 Apr 2009) Log Message php5-syck: Move from www to php category, with maintainer's permission While you're reconside

Re: xinstall glob question

Are these equivalent? A. eval xinstall -m 755 [glob {!${build.dir}/bin/*.dylib}] ${destroot}/$ {vtkExamplePath}/bin B. cd ${build.dir} for f in `find bin \! -name '*.dylib'`; do cp $f ${destroot}/${vtkExamplePath}/bin" done The only difference I see is the mode setting. Feel free to get a

Re: [50351] trunk/dports/x11

ryandes...@macports.org wrote: Revision 50351 Author ryandes...@macports.org Date 2009-04-29 10:30:58 -0700 (Wed, 29 Apr 2009) Log Message pango, pango-devel: still depend on gtk-doc, but don't use it, because doing so seems to be

xinstall glob question

Are these equivalent? A. eval xinstall -m 755 [glob {!${build.dir}/bin/*.dylib}] ${destroot}/${vtkExamplePath}/bin B. cd ${build.dir} for f in `find bin \! -name '*.dylib'`; do cp $f ${destroot}/${vtkExamplePath}/bin" done When using xinstall without resetting the file mode (ie, no -m option)

MacPorts article on ADC

Heyya people, quick hi after some serious lurking! I thought I'd forward this article on using MacPorts that appeared on ADC this february. Don't know if it's old news, as I say I've been lurking badly ;-), but it did catch my eye today as it was one of the top featured articles at the M

Re: hamcrest-core and backing out changes

Le 29 avr. 09 à 10:11, nox a écrit : Le 28 avr. 09 à 23:21, Blair Zajac a écrit : nox wrote: Le 28 avr. 09 à 19:04, Blair Zajac a écrit : Then, we'll need to delete hamcrest-core. Separate ports look better to me. hamcrest-library created in r50332. __

qt4-x11 and x11prefix

qt4-x11's qmake is causing built applications to use /usr/X11 instead of /opt/local for X11... This has caused some problems here, and I'm sure others might see it too: ./src/lib/animations/triangletriad_0001/Makefile:DEFINES = - D__USE_WS_X11__ -DUSE_DLOPEN ./src/lib/animations/triang

Re: hamcrest-core and backing out changes

Le 28 avr. 09 à 23:21, Blair Zajac a écrit : nox wrote: Le 28 avr. 09 à 19:04, Blair Zajac a écrit : Hi, Regarding hamcrest-core r50259 Revert r50223, this port is called hamcrest-core and thus should install only hamcrest-core, please create an hamcrest-library port if you need it.