Port is not enough

Sometimes application that we want to install from ports is not a version that we need
For whatever a reason is...

In my case it is about PHP.
I need latest 5.3.0-RC4 as I code in it.

I've downloaded sources for it, from php.net

What bugs me, is that there is no deinstall option.
Just make build, make install & make test

PS: For future reference how can I make "make" spit out all options I can issue to it?


My intention is to get rid of this installation, as soon as 5.3.0 comes into ports tree and then install it from there as usual.

I was thinking of using script(1) command to save installation output to file, so I can know, where are all files located, that needs to be removed.
But I will have to do that manually, which is kind of, unappealing solution.

Is there a better idea/solution?
 
For testing purpose you should use jails. No need to make such changes to production. This is your best option in a long term. Install anything, delete jail and recreate it again. No need to worry about security or uninstaller issues.
 
You could try editing the port's Makefile to download install the new version. It's usually what I do with the nvidia-driver.
 
I'll go for editing the port's Makefile.
I've never done that.

At the beginning of Makefile I've found some variables that are not defined anywhere.
For example: MASTER_SITE_PHP
I've searched whole php5 folder with:
grep MASTER_SITE_PHP * and nothing.
That is very confusing, as I can't set my own path for download

My aim is to point make file to download from this path:
http://downloads.php.net/johannes/php-5.3.0RC4.tar.bz2

Changing PORTVERSION var...

And continue installation as it would ordinary.
 
When installing software manually, it's generally a good idea to configure it to install to a single directory (./configure --prefix=/usr/local/appname). That way, uninstallation is as simple as rm -rf /usr/local/appname.

You can use ./configure --help to get a list of options for the configure script.

For make/gmake, I believe you have to read the Makefile to find all the targets listed.
 
phoenix said:
When installing software manually, it's generally a good idea to configure it to install to a single directory (./configure --prefix=/usr/local/appname). That way, uninstallation is as simple as rm -rf /usr/local/appname.

You can use ./configure --help to get a list of options for the configure script.

For make/gmake, I believe you have to read the Makefile to find all the targets listed.

Installation to one folder sounds good BUT PHP is very complex and will "seed" his files outside of it's installation dir.
Guaranteed!

/usr/local/appname will not work, as still few files will be left outside of it.

Where should I look for vars that appear in Makefile, but are not defined. Where are they defined?
 
Most of the time it's just a matter of changing the version number in a Makefile.

But I see php5 has quite a few patches in files. You would probably need to resolve any patching conflicts/failures.

MASTER_SITES_PHP is defined in /usr/ports/Mk/bsd.sites.mk. A lot of the real magic of the ports system is in the bsd.*.mk files ;)
 
@DutchDaemon - Thanks, I didn't knew that.
It also replies, some other issues, that I haven't posted, but are clear now ;)

@SirDice - Yep! I've found it too.
Regarding patches, current port version is 5.2.10
And is pretty diff from 5.3, as it brings additional new language syntax into PHP especially to OO part.

Will reevaluate which tactic to use... :q
 
Seeker said:
current port version is 5.2.10
And is pretty diff from 5.3, as it brings additional new language syntax into PHP especially to OO part.

Yes, indeed. goto is so object oriented, in a 1960's retro sort of way.

;)
 
mwatkins said:
Yes, indeed. goto is so object oriented, in a 1960's retro sort of way.

;)

Don't mock me.
If I've mentioned goto in OO context, then you could.

Regarding PHP's OO,
Support for namespaces, late static binding...

Some built in functions gained extra functionality, as they can be fed with extra param, etc..

But that is not a theme of this thread. :P
 
The ;) was an indication that my comment was intended to be humorous. I can see how you might have taken it as directed at you, but rest assured my lasers are pointed at those who made the inane decision to introduce "goto" into 5.3. I read elsewhere a comment labelling this latest move as making PHP a parody of itself and I find it hard to disagree with that also funny statement.

Had you been discussing a version prior to 5.3 I'd not have uttered a peep - it is just happy coincidence that what you seek, and goto, are both included in this latest release.

Then again PHP is a dogs breakfast to begin with, from its whacked installation process to still-flawed support for unicode, but you are quite correct, that's a discussion which belongs in another topic.
 
I agree "goto" has been abused but it's not all that bad. Even in OO.

When it comes down to the nitty gritty guess what a break or a switch statement compiles to. Sometimes gotos can make code more readable. Readable code creates less bugs.
 
@mwatkins - NP, I am not mad. ;)
Just you throw a digression which "web based" language, would you use better instead.

@SirDice - True
 
Seeker: I noticed you quoted "web based" above; nothing in PHP the language is unique for "web based" development. What makes PHP an easy sell to new developers is that you can include code in HTML with ease, and the underlying web servers are generally set up by default to enable this. I.e. a HTML only newbie decides to try out PHP and includes <? echo "Hello, world!"; ?> in her HTML et voila, it works.

That is powerful to be sure. But note this isn't a "language" feature but is a feature of the PHP/Apache (and other httpd) execution model. It isn't a unique feature to PHP but it is interesting that many other language communities have generally shied away from this approach, even though PHP-like implementations exist for many common so-called scripting languages.

Oops, I didn't answer your question -- I use Python as my default go-to language for web application development and for cross platform desktop apps too. One upon a time I did most of my work in classic ASP and PHP but no longer. I moved to Python quite some number of years ago, partly because it had a much better approach to dealing with alternate character sets (Unicode), partly because it was more consistent, and partly because it made doing certain things oh so much simpler. As I recall it was XMLRPC at the time which pushed me over the edge. What was painful in PHP was trivial in Python, and I found that experience repeated itself many times during my early exposure to Python. Fairly quickly I stopped comparing PHP to Python and never looked back.

Incidentally, Python has no goto. ;)

That was for a giggle only... I am not fixated on goto, I just thought the recent inclusion in PHP was funny on the surface. Looking deeper, it is likely being included to help in other areas where PHP has historically been deficient, like exception handling.

I'm not trying to knock PHP unfairly; these are just tools and a tool in the hand of a knowledgeable user is always going to be a useful tool.
 
Seeker said:
@mwatkins: I'm glad we've mutually concluded that PHP is the best.

I'm glad it's best for you, but it certainly doesn't meet my criteria of "best".

Back on topic (ports), Python 3.1 was released earlier this week; wonder which (PHP 5.3 or Python 3.1) will make Ports first?

Edit: This morning i see Python 3.1 (an excellent release by the way) is now in my ports tree as of July 6. No sign of PHP as yet.
 
Back
Top