probably teaching you to suck eggs, but just in case.....
the process i described using citrus perl and wxpar is equivalent to regular 
perl and par packer (pp).

both create a self-contained, no-dependencies executable containing the perl 
engine, required libraries and your source code. with optional storage of 
things like resources (images, config files, whatever).

the end-user can receive that exe onto a windows machine that does not have 
perl installed on it (or does and its perhaps a different version), and the exe 
will run as a windows program.
it is not an "installer" (your program will not end up in their program-files 
structure) - that would be a different process.

just wanna make sure we're all on the same (starting) page.

cheers,
Darren






On 19 Dec 2024, at 22:59, Brett Estrade <brett.estr...@gmail.com> wrote:

Thank you Darren, I found Citris Perl in the archives and was really curious 
about how it worked. I ran it, and was getting issues due to minimum Perl 
version (I think last update was for 5.16 or 5.24 - which frankly is fine with 
me! :-) ).

Would anyone be willing to document the process for Windows? I can do the work 
of verifying it and posting it somewhere it would be helpful to many.

I think the number #1 thing we can have for wxPerl and Perl programmers in 
general here is a well documented process to get the .exe or an msi for 
Windows, and that is what I'd like to be able to reproduce and document:
development environment set up (with or without wxGlade)
package things up into a EXE, such that the user needs only a single file (and 
not have to also install Perl or anything)
create an installer for Windows
See, I think we're long past the point that end-users/clients care things are 
written in Perl. They want the service or program to work, and it done at fair 
prices (Perl allows this due to programmer efficiency that can be achieved). 
What matters now is that Perl programmers have a well documented way to use 
their skills to create Windows applications that are useful, this will help 
many to carve out an existence as independant software creators. Which is 
something developers really need right now, especially Perl programmers. I know 
I do.

My main use cases:

1. create a windows GUI client for a web service I created (in Perl)
2. the ability to create standalone, non-networked GUI to do things - maybe 
database related - like old MS Access applications (not a GUI builder, the 
actual local DB application GUI)

Thoughts?

Brett

On Tue, Dec 17, 2024 at 4:10 AM Darren Harwood <dcharw...@gmail.com 
<mailto:dcharw...@gmail.com>> wrote:
> hi all,
> 
> when i used to do this......i'm thinking 2018, my process was this:
> 
> 1. windows OS and installed citrusperl. why citrusperl? because i could never 
> get the wx widgets and alien bits to build on my dev box - and yes, i wasted 
> days trying.
> 
> 2. normal processes to develop the perl script, wxFormBuilder tool to help 
> create the gui xrc, coz that's how i liked to load the gui components - but 
> anything (glade, handcrafting, etc) will do. make sure the script runs as 
> expected. i had some fairly cool multi-threaded apps running and they are 
> (surprisingly) still in daily use at a big customer!
> 
> 3. to build the EXE, you need to launch a citrus terminal as administrator 
> (important but afraid I don't recall why), like this:
> C:\citrusPerl\perl\bin\citrusterm.bat
> 
> then, to build with an annoying popup command prompt, do this:
> wxpar --gui -o Migration.exe Migration_tool.pl   
> 
> or, to build without an annoying popup command prompt, do this:
> wxpar -o Migration.exe Migration_tool.pl      
> 
> hope that's useful - or at least a pointer to the things we need to bring up 
> to date - or a list of what not to do? :)
> 
> cheers,
> Darren
> 
> 
> 
> 
> On 16 Dec 2024, at 08:12, Brett Estrade <brett.estr...@gmail.com 
> <mailto:brett.estr...@gmail.com>> wrote:
> 
> Hi, sorry for the late reply. Thank you for the replies.
> 
> I guess what I am suggesting is that there is a real need for well 
> documented, end-to-end workflows that are platform specific. My need happens 
> to be for Windows. A Mac workflow would be great, too.
> 
> What does this look like to me? It'd cover:
> 
> 1. installation steps of a development environment on the OS (e.g., Windows)
> 2. some notes about dev workflow (e.g., I like to start with wxGlade that 
> dumps Perl, but there might be a better way; I can get this working on Ubuntu 
> and Windos under Mobaxterm's installed Perl packages - which are cygwin based)
> 3. finally, the actual steps of packaging this up for distribution - be it 
> .exe, .msi, etc (for Windows is my main interest)
> 
> My Problem is conceptually, I understand all the bits and pieces but always 
> fall flat when it's time to roll a distro. I want to generate a Windows 
> distribution that is just a .exe and that I can distribute as a single file. 
> A .msi or installation bundle that handles everything would also be good, I 
> just have no idea how to generate it.
> 
> I guess I just need some major hand holding initially; but once I figure it 
> out I am happy to document it and maybe even share any tools I create to help 
> myself with the local process.
> 
> Thanks!
> Brett
> 
> On Sat, Nov 23, 2024 at 3:34 PM Johan Vromans <jvrom...@squirrel.nl 
> <mailto:jvrom...@squirrel.nl>> wrote:
>> On Fri, 22 Nov 2024 10:46:39 -0500, Don Peddicord wrote:
>> 
>> > The project I am
>> > on created a wrapper for the Perl interpreter which limited its execution
>> > to only the code we provide as part of our application.
>> 
>> I have a similar approach for my ChordPro tool based on Oliver
>> Betz' portable perl loader as used in the standalone exiftool program.
>> 
>> Basically I let the PAR packager collect everything needed, then unpack the
>> package to create a file hierarchy, add special libraries and create an
>> installer (InnoSetup for Windows, DMG for macOS).
>> 
>> There are several tricks involved to patch/relocate dynamic libraries to
>> make sure the program will only use the packaged libraries.
>> 
>> From the perspective of the end user it is a single thing that gets
>> installed, and a single desktop icon to click to start the program.
>> 
>> https://www.chordpro.org <https://www.chordpro.org/>
>> https://oliverbetz.de/pages/Artikel/ExifTool-for-Windows
> 
> 
> 
> --
> This email message is for the sole use of the intended recipient(s) and may 
> contain confidential and privileged information. Any unauthorized use or 
> disclosure is prohibited. If you are not the intended recipient, please 
> contact the sender by reply email and destroy all copies of the original 
> message. Thank you.
> 



--
This email message is for the sole use of the intended recipient(s) and may 
contain confidential and privileged information. Any unauthorized use or 
disclosure is prohibited. If you are not the intended recipient, please contact 
the sender by reply email and destroy all copies of the original message. Thank 
you.

Reply via email to