Greetings,
Given that the folks at PHP have decided that no one is allowed
to use PHP4 any longer. I've decided to *attempt* to install a copy
of PHP5 (cgi only) along side my already installed/configured, and
in use copy of PHP4 (apache_module, CLI, CGI). I spent some time
attempting to find
[EMAIL PROTECTED] wrote:
Greetings,
Given that the folks at PHP have decided that no one is allowed
to use PHP4 any longer. I've decided to *attempt* to install a copy
of PHP5 (cgi only) along side my already installed/configured, and
in use copy of PHP4 (apache_module, CLI, CGI). I spent some
Quoting Chris St Denis [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
Greetings,
Given that the folks at PHP have decided that no one is allowed
to use PHP4 any longer. I've decided to *attempt* to install a copy
of PHP5 (cgi only) along side my already installed/configured, and
in use copy of
[EMAIL PROTECTED] wrote:
Quoting Chris St Denis [EMAIL PROTECTED]:
[EMAIL PROTECTED] wrote:
Greetings,
Given that the folks at PHP have decided that no one is allowed
to use PHP4 any longer. I've decided to *attempt* to install a copy
of PHP5 (cgi only) along side my already
Quoting Chuck Swiger [EMAIL PROTECTED]:
Hi--
On Aug 26, 2008, at 12:42 PM, [EMAIL PROTECTED] wrote:
Given that the folks at PHP have decided that no one is allowed
to use PHP4 any longer. I've decided to *attempt* to install a copy
of PHP5 (cgi only) along side my already
Hi--
On Aug 26, 2008, at 12:42 PM, [EMAIL PROTECTED] wrote:
Given that the folks at PHP have decided that no one is allowed
to use PHP4 any longer. I've decided to *attempt* to install a copy
of PHP5 (cgi only) along side my already installed/configured, and
in use copy of PHP4 (apache_module,
--On August 26, 2008 2:09:27 PM -0700 [EMAIL PROTECTED] wrote:
I'll have a close look at $LOCALBASE. That sounds like a good
candidate. With any luck, it'll also cover extensions, ini(s), and
related libs. :)
Please be aware that if you change ${LOCALBASE} you change it for *all*
Quoting Paul Schmehl [EMAIL PROTECTED]:
--On August 26, 2008 2:09:27 PM -0700 [EMAIL PROTECTED] wrote:
I'll have a close look at $LOCALBASE. That sounds like a good
candidate. With any luck, it'll also cover extensions, ini(s), and
related libs. :)
Please be aware that if you change
Quoting [EMAIL PROTECTED]:
Quoting Paul Schmehl [EMAIL PROTECTED]:
--On August 26, 2008 2:09:27 PM -0700 [EMAIL PROTECTED] wrote:
I'll have a close look at $LOCALBASE. That sounds like a good
candidate. With any luck, it'll also cover extensions, ini(s), and
related libs. :)
Please be
--On August 26, 2008 3:05:25 PM -0700 [EMAIL PROTECTED] wrote:
Hello, and thank you very much for your reply.
Yes. After looking closely at the variable, I discovered that also.
So I used the PREFIX=/usr/local/php5. But as I build it (via
php5-extensions)
I am not seeing the PREFIX variable
On Tue, Aug 26, 2008 at 06:04:36PM -0500 I heard the voice of
Paul Schmehl, and lo! it spake thus:
If you plan on doing this often, pkgtools.conf is your best bet. If you
plan on doing it once, commandline is probably the easiest and quickest.
I would say using ports-mgmt/portconf would be
Quoting Paul Schmehl [EMAIL PROTECTED]:
--On August 26, 2008 3:05:25 PM -0700 [EMAIL PROTECTED] wrote:
Hello, and thank you very much for your reply.
Yes. After looking closely at the variable, I discovered that also.
So I used the PREFIX=/usr/local/php5. But as I build it (via
Quoting Matthew D. Fuller [EMAIL PROTECTED]:
On Tue, Aug 26, 2008 at 06:04:36PM -0500 I heard the voice of
Paul Schmehl, and lo! it spake thus:
If you plan on doing this often, pkgtools.conf is your best bet. If you
plan on doing it once, commandline is probably the easiest and quickest.
I
Hello Jeremy, and thank you for your /very/ informative reply.
You rock! :)
Quoting Jeremy Chadwick [EMAIL PROTECTED]:
On Mon, Feb 25, 2008 at 11:35:23PM -0800, Chris H. wrote:
But am struggling with finding the port(s) equivalent. If there isn't
one, I'd be more that happy to dedicate a
On Mon, Feb 25, 2008 at 11:35:23PM -0800, Chris H. wrote:
But am struggling with finding the port(s) equivalent. If there isn't
one, I'd be more that happy to dedicate a domain/ web site solely to
providing this resource. Perhaps a wiki that I, and anyone else can
add the WITH_/WITHOUT_
Hello, and thank you for your reply.
Quoting Yuri Pankov [EMAIL PROTECTED]:
On 02/26/2008 10:35, Chris H. wrote:
Hello, and thank you for your reply.
Quoting Ruslan Ermilov [EMAIL PROTECTED]:
On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote:
Hello All,
Maintaining a make.conf file
On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote:
Is there, or does anyone maintain a KNOBS list possibly categorized
by application/port/version, etc...?
ports/KNOBS?
mcl
___
freebsd-stable@freebsd.org mailing list
On 02/26/2008 10:35, Chris H. wrote:
Hello, and thank you for your reply.
Quoting Ruslan Ermilov [EMAIL PROTECTED]:
On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote:
Hello All,
Maintaining a make.conf file can be a fairly daunting task within
itself. But when upgrading, it becomes
On Tue, Feb 26, 2008 at 03:05:09AM -0800, Chris H. wrote:
Additionally, the WITH/WITHOUT variables seen in the Makefile are not
always what they seem. For ports that use OPTIONS, you cannot define
these on the command-line (e.g. make WITHOUT_FRUIT=yes);
I believe that /should/ be:
Quoting Mark Linimon [EMAIL PROTECTED]:
On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote:
Is there, or does anyone maintain a KNOBS list possibly categorized
by application/port/version, etc...?
ports/KNOBS?
Yes. I have been aware of that file since it has been available in the
Quoting Jeremy Chadwick [EMAIL PROTECTED]:
On Tue, Feb 26, 2008 at 03:05:09AM -0800, Chris H. wrote:
Additionally, the WITH/WITHOUT variables seen in the Makefile are not
always what they seem. For ports that use OPTIONS, you cannot define
these on the command-line (e.g. make
On Tue, Feb 26, 2008 at 03:49:48AM -0800, Chris H. wrote:
Quoting Mark Linimon [EMAIL PROTECTED]:
On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote:
Is there, or does anyone maintain a KNOBS list possibly categorized
by application/port/version, etc...?
ports/KNOBS?
Yes. I have
Note that the phpmyadmin entry in our make.conf has no *functional*
purpose, because phpmyadmin uses the OPTIONS framework. It's used
solely as a reminder whenever I do make rmconfig and need to re-pick
what options to use.
Is the idea to move all the ports over to the OPTIONS stuff ? That's
On Tue, Feb 26, 2008 at 2:03 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
Additionally, the WITH/WITHOUT variables seen in the Makefile are not
always what they seem. For ports that use OPTIONS, you cannot define
these on the command-line (e.g. make WITHOUT_FRUIT=yes); you absolutely
MUST do
On Tue, Feb 26, 2008 at 06:33:37AM -0600, Scot Hetzel wrote:
On Tue, Feb 26, 2008 at 2:03 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
Additionally, the WITH/WITHOUT variables seen in the Makefile are not
always what they seem. For ports that use OPTIONS, you cannot define
these on the
Hello All,
Maintaining a make.conf file can be a fairly daunting task within
itself. But when upgrading, it becomes even more laborious. Peeking
into the port Makefile to discover any /new/, or /changed/ knobs is
standard fare. But it's not always obvious exactly /what/ the
WITH_this, or
On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote:
Hello All,
Maintaining a make.conf file can be a fairly daunting task within
itself. But when upgrading, it becomes even more laborious. Peeking
into the port Makefile to discover any /new/, or /changed/ knobs is
standard fare. But
Hello, and thank you for your reply.
Quoting Ruslan Ermilov [EMAIL PROTECTED]:
On Mon, Feb 25, 2008 at 09:55:22PM -0800, Chris H. wrote:
Hello All,
Maintaining a make.conf file can be a fairly daunting task within
itself. But when upgrading, it becomes even more laborious. Peeking
into the
28 matches
Mail list logo
