On Jul 13, 2013, at 12:11, Gustaf Neumann wrote:
> Am 13.07.13 15:53, schrieb Lawrence Velázquez:
>> Bootstrapping from source would be weird, for one. I suppose we'd bundle Tcl
>> with the source, install using that one, install the Tcl port, and reinstall
>> off of the port? It sounds gross, bu
On Jul 13, 2013, at 08:37, Lawrence Velázquez wrote:
> On Jul 13, 2013, at 8:25 AM, Gustaf Neumann wrote:
>
>> The macports private version is installed under
>> /opt/local/share/macports/{bin|lib|include|man},
>> so one can use this tclsh via preplacing
>> /usr/bin/tclsh in /opt/local/bin/port
Ok, if I just move it outside pre-configure it seems to work.
Thanks,
David
On Sat, Jul 13, 2013 at 5:52 PM, David Strubbe wrote:
> I see. So, is there a place I can move this piece of code, or should I
> just write an error message by hand instead of using
> require_active_variants?
>
>
> On S
I see. So, is there a place I can move this piece of code, or should I just
write an error message by hand instead of using require_active_variants?
On Sat, Jul 13, 2013 at 5:07 PM, Joshua Root wrote:
> On 2013-7-14 06:44 , David Strubbe wrote:
> > Hi all,
> >
> > I am trying to add MPI support
On 2013-7-14 06:44 , David Strubbe wrote:
> Hi all,
>
> I am trying to add MPI support to my octopus port, and trying to find
> the proper way of enforcing consistent Fortran versions. I put the
> following code into pre-configure, which almost seems to do the job. The
> error is not triggered, an
Hi all,
I am trying to add MPI support to my octopus port, and trying to find the
proper way of enforcing consistent Fortran versions. I put the following
code into pre-configure, which almost seems to do the job. The error is not
triggered, and the message gives the correct Fortran compiler in th
Am 10.07.13 00:25, schrieb Lawrence Velázquez:
For selective definition-time substitution, you could use string map
(http://wiki.tcl.tk/37332#pagetoc04c6ab3f):
foreach {foo.version foo.string} ${foo.versions} {
set script {
subport foo-${foo.version} {
On Jul 13, 2013, at 2:31 PM, Jordan K. Hubbard wrote:
> On Jul 13, 2013, at 6:53 AM, Lawrence Velázquez wrote:
>
>> Bootstrapping from source would be weird, for one. I suppose we'd bundle Tcl
>> with the source, install using that one, install the Tcl port, and reinstall
>> off of the port?
On Jul 13, 2013, at 1:11 PM, Gustaf Neumann wrote:
> not sure, i understand correctly. If you suggest to run port
> itself on its own port, this can be dangerous:
> - a user might deinstall tcl and that would kill ports alltogether
The MacPorts port would explicitly depend on tcl. Removing tcl w
I reset all 3 slaves.
-Bill
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Am 13.07.13 15:53, schrieb Lawrence Velázquez:
Bootstrapping from source would be weird, for one. I suppose we'd
bundle Tcl with the source, install using that one, install the Tcl
port, and reinstall off of the port? It sounds gross, but it would
only have to happen for the initial install.
n
On Jul 13, 2013, at 10:38 AM, Lawrence Velázquez wrote:
> It can, with some caveats.
>
> http://arstechnica.com/apple/2005/04/macosx-10-4/4/#64bit
>
> https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64bitPorting/intro/intro.html
On second glance, neither link I just se
On Jul 13, 2013, at 9:59 AM, Joshua Root wrote:
> On 2013-7-13 06:28 , Ryan Schmidt wrote:
>>
>> Or are you asking how to determine programmatically what archs would be
>> supported? Assuming we don't need to run any built program at build time,
>> the answer is probably all four architectures
On 2013-7-13 06:28 , Ryan Schmidt wrote:
>
> Or are you asking how to determine programmatically what archs would be
> supported? Assuming we don't need to run any built program at build time, the
> answer is probably all four architectures on Tiger and Leopard, and the two
> Intel architecture
On Jul 11, 2013, at 3:25 AM, Ryan Schmidt wrote:
> I suppose so. But there's still the idea of self-hosting MacPorts, where
> MacPorts would come with the MacPorts port pre-installed and the selfupdate
> mechanism would be just a thin shim around updating the MacPorts port:
>
> https://trac.ma
On Jul 13, 2013, at 8:25 AM, Gustaf Neumann wrote:
> The macports private version is installed under
> /opt/local/share/macports/{bin|lib|include|man},
> so one can use this tclsh via preplacing
> /usr/bin/tclsh in /opt/local/bin/port by
> /opt/local/share/macports/bin/tclsh8.5
/opt/local/share/
On Sat, Jul 13, 2013 at 02:25:27PM +0200, Gustaf Neumann wrote:
> Attached is a script that does the full cycle, albeit for tcl 8.5. and
> tcllib 1.15;
Thank you, that's very helpful. I'll see if I can get this into base (or
at least a branch) next week.
> so one can use this tclsh via preplacing
On Fri, Jul 12, 2013 at 03:28:23PM -0500, Ryan Schmidt wrote:
> Or are you asking how to determine programmatically what archs would
> be supported? Assuming we don't need to run any built program at build
> time, the answer is probably all four architectures on Tiger and
> Leopard, and the two Int
Am 10.07.13 00:01, schrieb Clemens Lang:
Of course, if you want to come up with a script that will build Tcl 8.6
somwhere in a private prefix with --enable-threads and the thread
module, be my guest :)
Attached is a script that does the full cycle, albeit for tcl 8.5.
and tcllib 1.15;
This wou
On Jul 13, 2013, at 03:58, take...@macports.org wrote:
> Revision: 108113
> https://trac.macports.org/changeset/108113
> Author: take...@macports.org
> Date: 2013-07-13 01:58:56 -0700 (Sat, 13 Jul 2013)
> Log Message:
> ---
> magicspp: fixed undefined X11 symbol error, clos
20 matches
Mail list logo
