Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29
  1. #11
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    3,073
    Quote Originally Posted by mherger View Post
    > The installer still uses Program Files (x86) which I need to change.

    Are you using InnoSetup? Maybe it requires an update, too? I haven't
    used it in a long time. Would it be able to configure services etc.?
    [color=blue]
    Yes, I'm currently using the version from the platforms win32 folder.
    There is a much newer version available with full 64bit app install support that I plan to upgrade to once the par-packer binaries are done.
    Looks like sc.exe can be run from innosetup to install/uninstall windows services.

    Quote Originally Posted by mherger View Post
    cygwin always was about the first thing I'd install on a new Windows box
    :-). But great if you can deal without it!
    Well, I do have the newer msys64 installed, that I use to build the 64bit helper binaries, but it's not available from the windows cmd prompt.
    Nice thing about msys64 is there's no cygwin1.dll or equivalent runtime dlls needed.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  2. #12
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,775

    LMS for Windows using Strawberry Perl

    > Well, I do have the newer msys64 installed, that I use to build the
    > 64bit helper binaries, but it's not available from the windows cmd
    > prompt.
    > Nice thing about msys64 is there's no cygwin1.dll or equivalent runtime
    > dlls needed.


    Interesting: some of the msys2 tools are based on cygwin, but the
    resulting binaries are Windows only.

    "The unixy tools in MSYS2 are directly based on Cygwin, so there is some
    overlap there. While Cygwin focuses on building Unix software on Windows
    as is, MSYS2 focuses on building native software built against the
    Windows APIs."

  3. #13
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    3,073
    I'd like to revisit providing separate par-packer compiled binaries for each component.

    Is it necessary? What benefit does it provide over bundling a copy of the portable strawberry perl within the lms installer and running from the source?
    You can move/rename the perl directory and it will still work, so perl can be installed within the C:\program files\Squeezebox folder structure.
    Setting up lms as a windows service works using NSSM running perl.exe, slimserver.pl and parameters directly in the service definition.

    Having perl and sources available on windows would bring the release in line with the other release flavours and allow code changes for troubleshooting issues.

    So far, I've found the par-packer build process fragile and debugging crashes extremely tedious. A crash usually happens in a dll and only reported with a name that a hex number.dll. You then have to find it in the par-cache temp folder, search the strings within the dll to determine which perl module/component it's related.

    I can continue with the compiled binary builds but I'm not sure it the best option for the future.

    I'd appreciate your thoughts on moving to a source based release. The lms sources would still be stripped down to only what's needed for windows.

    Thanks.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  4. #14
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,775

    LMS for Windows using Strawberry Perl

    > I'd like to revisit providing separate par-packer compiled binaries for
    > each component.


    Great!

    > Is it necessary?


    No. I'm even open to dropping all the helpers.

    > What benefit does it provide over bundling a copy of
    > the portable strawberry perl within the lms installer and running from
    > the source?


    "you have to install Perl" might scare people away. I think that really
    is it.

    So I was wondering whether we could have two installers: the "full"
    version bundling Strawberry Perl with LMS. And the LMS only installer
    (used in updates), only installing the LMS code. I haven't looked into
    Strawberry Perl's licensing and what not. Just an idea.

    > Setting up lms as a windows service works using 'NSSM'
    > (https://nssm.cc/) running perl.exe, slimserver.pl and parameters
    > directly in the service definition.


    What's the licensing model there?

    > Having perl and sources available on windows would bring the release in
    > line with the other release flavours and allow code changes for
    > troubleshooting issues.


    Agreed.

    > I can continue with the compiled binary builds but I'm not sure it the
    > best option for the future.


    If I may say so... I'd prefer you to work on a simple, stable
    installation procedure leveraging raw Strawberry Perl, than wasting time
    trying to figure out the issues with building binaries.

    > I'd appreciate your thoughts on moving to a source based release. The
    > lms sources would still be stripped down to only what's needed for
    > windows.


    Great! An they would only be include once, not once per binary!

    I know that you don't use Cygwin. But how are the chances that the build
    process would still work with Cygwin? It would be great if I didn't have
    to maintain another build host...

  5. #15
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,775

    LMS for Windows using Strawberry Perl

    Oh, one more thing: do you have your WIP code somewhere in a git repository?

  6. #16
    Senior Member
    Join Date
    May 2005
    Location
    In a house
    Posts
    1,907
    Quote Originally Posted by mherger View Post
    >
    "you have to install Perl" might scare people away. I think that really
    is it.
    I've been having folks install Strawberry Perl (and prior to that, ActivePerl) for 10 years. It's not that big a deal for them.

    Originally, I advised for the Portable version, but changed course on that years ago and recommend the installed version. It's just easier to write documentation.

    Further, I have a script that cpanm's the required modules necessary for my various software packages. That seems to be sufficient.

    However, for what I'm doing, typically using the latest Perl and modules is OK, but there are times when I've had to advise a particular version becomes some module fails on the most recent S.P. But this is generally pretty rare.

  7. #17
    jvromans@squirrel.nl
    Guest

    LMS for Windows using Strawberry Perl

    Just chiming in...

    I have long term experience with preparing user-friendly deliverables for
    complex perl programs. Basically it is a way of packaging perl, the
    necessary libraries and modules and the rest of the code/data in a
    directory structure (kind of virtual environment) and using a specially
    built version of perl that stays inside the virtual environment. The whole
    thing is then packaged using InnoSetup (Windows), dmg (MacOS) or Appimage
    (Linux).

    >From the user perspective, she downloads an installer (e.g. Windows .exe

    file), runs it and its contents is installed where the user wants (usually
    C:\Program Files (x86)\) together with icons on the deskstop to
    start the program.

    I use this a.o for the ChordPro program. Feel free to download an installer
    from https://github.com/ChordPro/chordpro...ownload/R5.985
    and see how it works.

    Important: Getting the packaging right can be a bit tedious. But once it
    is done building new kits it is a whimp.

    -- Johan

  8. #18
    jvromans@squirrel.nl
    Guest

    LMS for Windows using Strawberry Perl

    On Wed, 2 Feb 2022 19:46:22 +0100, Johan Vromans <jvromans (AT) squirrel (DOT) nl>
    wrote:

    > Important: ...


    Also important: There is no run-time overhead (no on-the-fly unpacking into
    hidden folders).

  9. #19
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    3,073
    Quote Originally Posted by mherger View Post
    No. I'm even open to dropping all the helpers.
    Thanks. I'll keep that in mind going forward.

    Quote Originally Posted by mherger View Post
    "you have to install Perl" might scare people away. I think that really
    is it.

    So I was wondering whether we could have two installers: the "full"
    version bundling Strawberry Perl with LMS. And the LMS only installer
    (used in updates), only installing the LMS code. I haven't looked into
    Strawberry Perl's licensing and what not. Just an idea.
    I'd been thinking along those lines as well.

    But if we have 2 installers, why not just install the official strawberry perl msi once as MrC has identified from experience?

    The LMS installer should be able to be changed to handle the dependency and install perl if it's not there, keeping in mind that we will be tied to a specific version of SB Perl, just like Linux.

    Quote Originally Posted by mherger View Post
    > Setting up lms as a windows service works using 'NSSM'
    > (https://nssm.cc/) running perl.exe, slimserver.pl and parameters
    > directly in the service definition.[/color]

    What's the licensing model there?
    Yes, I am aware of possible licensing issues, not specifically with the NSSM, but in general. It's always a concern, but I've not investigated any of that yet.


    Quote Originally Posted by mherger View Post
    If I may say so... I'd prefer you to work on a simple, stable
    installation procedure leveraging raw Strawberry Perl, than wasting time
    trying to figure out the issues with building binaries.
    Yes of course. I'd appreciate your direction as we move along.

    Quote Originally Posted by mherger View Post
    Great! An they would only be include once, not once per binary!

    I know that you don't use Cygwin. But how are the chances that the build
    process would still work with Cygwin? It would be great if I didn't have
    to maintain another build host...
    Currently, I just add the unix util folder location to the PATH before running buildme. I only have the commands needed for buildme to success, it's only 9MB, no installer, no extra cruft.

    However, I have no issues with moving to as close as possible to the current win32 build system. In which case it would be helpful to have the version details for all the tools, sans the PDK of course.

    Quote Originally Posted by mherger View Post
    Oh, one more thing: do you have your WIP code somewhere in a git repository?
    I've added a link in the first post to the platform wip sources.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  10. #20
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    3,073
    Quote Originally Posted by jvromans@squirrel.nl View Post
    Just chiming in...

    I have long term experience with preparing user-friendly deliverables for
    complex perl programs. Basically it is a way of packaging perl, the
    necessary libraries and modules and the rest of the code/data in a
    directory structure (kind of virtual environment) and using a specially
    built version of perl that stays inside the virtual environment. The whole
    thing is then packaged using InnoSetup (Windows), dmg (MacOS) or Appimage
    (Linux).

    >From the user perspective, she downloads an installer (e.g. Windows .exe

    file), runs it and its contents is installed where the user wants (usually
    C:\Program Files (x86)\) together with icons on the deskstop to
    start the program.

    I use this a.o for the ChordPro program. Feel free to download an installer
    from https://github.com/ChordPro/chordpro...ownload/R5.985
    and see how it works.

    Important: Getting the packaging right can be a bit tedious. But once it
    is done building new kits it is a whimp.

    -- Johan
    Thank you for the suggestion. Unfortunately, that link returns a 404.

    I tried looking into ChordPro in the beginning but it appears to be a dead project, or perhaps, they've just moved development.

    Please correct me if I'm mistaken.

    Quote Originally Posted by jvromans@squirrel.nl View Post
    On Wed, 2 Feb 2022 19:46:22 +0100, Johan Vromans <jvromans (AT) squirrel (DOT) nl>
    wrote:

    > Important: ...


    Also important: There is no run-time overhead (no on-the-fly unpacking into
    hidden folders).
    Yes this is actually very painful. Especially the first time you run a new build.

    The AV services chews CPU for a long time scanning the thousands of files as they're expanded into the par-cache temp folder and it's repeated for every exe.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •