Bundle Busybox (Idea)

[thestr4ng3r]

Right now, all commands are just run without any shell and manually calling a shell in a build script would break Windows compatibility, so I think it could be extremely convenient to have r2pm always use a shell and some basic unix tools that it provides by itself, which could be done by bundling Busybox.

This is a port for Windows: https://frippery.org/busybox/ I didn't try it myself, but doesn't look bad.

[radare]

r2 have all those commands you need for r2pm already, cp, mv, rm, ls, cat ... if you need any other one we can add it. i know having r2pm depend on r2 is kind of scary if you want to install multiple versions of r2 with r2pm, using it like a kind of version manager.. but i would prefer to not add more stuff and try to make build/install scripts as simple as possible, maybe adding some kind of supported-os arrays to avoid windows people trying to build non-portable software, or just restrict windows user to only use binary packages, because at the end windows have no serious shell or opensource compiler to play with it withouht concenrs

On 31 Aug 2019, at 14:51, Florian Märkl notifications@github.com wrote:

Right now, all commands are just run without any shell and manually calling a shell in a build script would break Windows compatibility, so I think it could be extremely convenient to have r2pm always use a shell and some basic unix tools that it provides by itself, which could be done by bundling Busybox.

This is a port for Windows: https://frippery.org/busybox/ https://frippery.org/busybox/ I didn't try it myself, but doesn't look bad.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/radareorg/r2pm/issues/47?email_source=notifications&email_token=AAG75FQVPLJ3T6J5MYYZIXLQHJSMJA5CNFSM4ISTTGIKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HISXTFQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG75FTB3GXXFFCCGGALWNLQHJSMJANCNFSM4ISTTGIA.

[qbarrand]

Hi @thestr4ng3r, do you have a use case in mind? I was thinking that it is a better idea to specify which files are r2 plugins that should be copied to the appropriate directory, e.g. in an out section of the YAML file:

out:
  - file: <a file compiled file>
    type: exe | lib-shared

This would make r2pm able to fully control the plugin lifecycle, as it knows exactly what files need to be removed when you uninstall a package.

I'm very open to suggestions though.

[thestr4ng3r]

Yes, this would definitely be nice. For the out entries, it might also be useful to specify a txt-file with a list of files to be installed and prefix-relative directories in addition to pre-defined types for exe, lib, etc.

But for packages that should be built from source, it will still be necessary to execute some scripts like the current r2pm does. Also, r2pm binary packages building could be automated using r2pm itself. If some basic unix tools are provided, this might even work on Windows if r2pm can set up the environment for msvc by calling the respective bat files.

[qbarrand]

But for packages that should be built from source, it will still be necessary to execute some scripts like the current r2pm does.

What scripts? Are you referring to things like ./configure?

[thestr4ng3r]

For example, yes. But even when using something like cmake, I would have to call it like cmake -DCMAKE_INSTALL_PREFIX="$R2PM_PLUGDIR" .. which needs something to resolve the $R2PM_PLUGDIR part.

[qbarrand]

I was thinking of using Go's text/template for this. Something like:

build:
  # macos:
  # - ...

  linux:
    - make CFLAGS="{{ .R2HeadersPath }}"

out:
  - file: myplugin.so
    type: lib-shared

This way we would completely avoid any shell dependency.

[thestr4ng3r]

Yes, this can work too in this case. However keep in mind that even in this case, you depend on make to be available and the Makefile could even depend on GNU make features. (Though make isn't part of busybox too)

[radare]

And do you think providing busybox on windows will be enough to make them work? Also i think r2pm should work like docker. Aka providing some commands abstracted from the OS ones to copy files and such. For building. I would prefer to keep it like it is right now . So basicslly, if u need meson, make the pkg depend on the meson pkg. windows builds can have this pkg as dependency if needed. But imho its better to override the configure/makefiles hell on windows if possible

On 2 Sep 2019, at 10:42, Quentin Barrand notifications@github.com wrote:

But for packages that should be built from source, it will still be necessary to execute some scripts like the current r2pm does. What scripts? Are you referring to things like ./configure?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[radare]

Except for doing conditionals and loops

On 2 Sep 2019, at 15:49, Quentin Barrand notifications@github.com wrote:

I was thinking of using Go's text/template for this. Something like:

...

install: linux:

• make CFLAGS="{{ .R2HeadersPath }}"

out:

• file: myplugin.so type: lib-shared

  ...

  This way we would completely avoid any shell dependency.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[thestr4ng3r]

And do you think providing busybox on windows will be enough to make them work? Also i think r2pm should work like docker. Aka providing some commands abstracted from the OS ones to copy files and such.

Yes, exactly that would be my idea too. I don't know if busybox would be enough, MSYS2 would definitely work but it's much bigger.

[qbarrand]

However keep in mind that even in this case, you depend on make to be available and the Makefile could even depend on GNU make features.

I guess that some make-like software will always be needed anyway to build plugins. What issue would something like busybox solve in this case?

Also i think r2pm should work like docker. Aka providing some commands abstracted from the OS ones to copy files and such. For building.

Could you explain why? I don't really understand why there should be a r2pm cp, for instance.

[pelijah]

vcpkg for WIndows downloads portable versions of required tools (e.g. cmake, ninja, python3+meson) to own subdir. But without Windows SDK users can't build plugins even if we will use clang-cl. Minimal installation version of Windows 10 SDK requires downloading ~400MB.

[pelijah]

So I don't see any better way than distributing binaries.

[XVilka]

I don't think busybox will help, if user wants to build the thing from sources we can maybe just call a choco install <whatever is required> from r2pm, but that's it.

[XVilka]

I am closing this, reopen if you disagree.