Package php binaries + php script into one single executable file

I actually wrote that. I never imagined someone would actually find that
useful!

If you don't mind having a few external dlls, you can use dl (ick!) to
load the extensions.

I gave up supporting that because compiling the custom lightweight stubs
took more work than I cared for. I am considering reviving the project
and this time not writing in PHP (PHP should really not be used for GUIs
IMO).

If you can wait a bit. I can setup my code (Visual C++ projects mostly)
on GitHub so you can clone and compile whatever stubs you want.

If you cannot wait, or want to tinker, here is a thread I wrote that
talks about making a static/stub exe:

http://winbinder.org/forum/viewtopic.php?f=10&t=1178

Good luck!

Alec Gorge

Found one interesting tool named PHPACK :
http://winbinder.org/forum/viewtopic.php?f=8&t=1148 (windows only)

http://winbinder.org/forum/viewtopic.php?f=8&t=1148Tool is no more
supported (ended mid-2010), but seems to be working with PHP 5.3.

What it does : package php5ts.dll + custom php scripts into one .exe
(windows only).

Tested with my phar file generated a 3Mb exe file (not that big).

But limited support for extension (few statically linked extension).

I have not yet tested the exe file on a blank box (i.e. where php not
already installed).

Seems to be an interesting solution for my windows users.

Other ideas ?

oha

2011/3/15 Olivier Hoareauolivier@phppro.fr

Hi Tomas !

Thanks for your proposals.

Create .deb package and make it dependent on PHP for Debian/Ubuntu. Debian
has docs and tools that allow to do that. PHP is in standard Debian/Ubuntu
software repository.

This solution does not provide me one of the goal I need to reach : that my
users be able to use the tool even if they already have PHP installed on
their system but with a version not compatible with the tool.
Let me explain why : the goal of the tool is to provide command line
actions for team (dev team) members, such as the ones (but not only)
provided by tools like zf / sf / maven (but not sticked to a specific
framework and working with all frameworks), so the targeted users are
already using PHP but with specific version of PHP (depending on the need
for the application they are currently developing). I would like to be able
to provide all the features my tool provide to those teams BUT without the
need for these team to "upgrade" the version of PHP they are using on their
desktop (mostly PHP 5.2)

Distribute .phar package alone for users who already have PHP. List PHP
extensions your package depends on.

This solution is already in use, but not perfect, for the problem I
described above, at least, because a small percentage of my targetted users
(at this moment) are using PHP 5.3+

Create automated installer for Windows which downloads PHP from the
network. See microsoft web platform installer for more ideas.

This is a possible solution if installing PHP in a custom directory without
system-wide installation and if 2 version of PHP can coexist on the same
filesystem without conflicts on extensions/php.ini/system variables, do you
have links ? (I will google it)

IMHO your package license is not compatible with PHP license. You can't

distribute PHP with BSD license.

OK, I was not aware of this limitation.
It is not a problem to modify the license of the tool to one that is
compatible with PHP license, my purpose is to share something, not to sell
it. Do you (are others) have advice on this specific points ?

Thanks !

Olivier H.

--

Tomas

You are free to repackage PHP debs and make your package depend on Debian
PHP 5.3 or your PHP 5.3.

OK

I don't think that people are gonna like that kind of approach, having two
binaries with one of them coming from custom source should raise some
concerns and you won't like the prospects of maintaining PHP for older
Debian/Ubuntu versions.

My users currently does not matter about this kind of problem, they want to
be able to download a binary, put it in a directory and use it in command
line, whatever it contains.
The features provided by the tool are not php-centric (not only at least),
so I can target teams that do not know anything of php and how it needs to
be installed.

This method of distribution [phar] targets users who can read documentation
and
understand what "depends on PHP 5.3" means.

Lots of users I target does not know differences between php 5.2 and php
5.3, some of them don't know even that php 5.3 exists or what phar is.
For the others, it is a possible solution, but not allowing multiple php
version on same box and requiring that I maintain multiple package of the
application (I will have to, but the less package I have to maintain the
more time I will have to improve features).

I am not a lawyer. You can distribute installer which downloads PHP from

the net (windows.php.net or its mirrors). If you repackage PHP and
distribute PHP itself and your code in one bundle, your bundle license
must be compatible with PHP license. that's what any layman would think.
Don't mix incompatible licenses in one package.

It was not my intention to mix licenses, so I have to use last "PHP
License", not a problem, no ?

If small percentage of your targets use PHP 5.3, then your goal should be

to make your package compatible with older PHP version. If you have
deliberately coded with namespaces or other stuff from PHP 5.3, recheck
your coding manual. What is more important for you? Proving to yourself
that you can use complex language constructs in your code or reaching your
target users.

I already have PHP 5.2 compatible version of the tool, the PHP 5.3 is a
complete rewrite making use of namespace (a lot) / DIR (a few) / closure
(a few) / phar (a few)
In order to be able to maintain my tool I want to use PHP 5.3.

As I said, this is not a commercial tool, I am distributing it freely, my
purpose is not to waste my time to maintain differents version but to be
able to target maximum of people that needs this kind of features (i.e. code
generation, command line aliases, virtual tree layout, custom command
writing in pure php, i18n, trace/logging, automatic db upgrade, unit
testing, continuous integration bindings ...)

The tool of Alec seems to be very interesting for my purpose, so I will
investigate. I am so sorry that today there is not an official way of
packaging a standalone php application for people that don't have php
already installed on their box, it could contribute to enhance php
promotion.

Thank you !

oha

--
Tomas