Thread: paw options

Finally getting started on the app that will map in paths before launching a command for my cross-platform & cross-distro solution to development in general, idea being "develop for cross-platform before developing for native" unlike the current "develop for native before developing for developing for cross-platform" paradigm we currently have on all platforms & distros.

What I'm fishing for here is options that would be desired/needed for flexibility regarding development and usage with things like flatpak, this is what I currently have:

Code:

OPTION options[]
{
	/* Compile to ".../" - intended for developers, app may look for
	 * PAW_TODIR environment variable */
	{ "-o" },
	{ "--todir" },
	/* Launch from ".../" [...], apps may look for PAW_WHERE environment
	 * variable */
	{ "-c" },
	{ "--build" },
	{ "--where" },
	/* Launch CMD [...] with PATH prefixed with release paths, example:
	 * paw -c ~/ ./ "./test path/" -x=x86,windows rm test.txt
	* Would be the roughly the same as:
	 * cd ~/ && PATH=/abi/paw/fast/windows/x86/bin:$(PATH) && rm test.txt
	 * cd ./ && PATH=/abi/paw/fast/windows/x86/bin:$(PATH) && rm test.txt
	 * cd "./test path" && PATH=/abi/paw/fast/windows/x86/bin:$(PATH) && rm test.txt
	* Or:
	 * cd %USERPROFILE% && PATH=C:\abi\paw\fast\windows\x86\bin;%PATH% && rm test.txt
	 * cd ./ && PATH=C:\abi\paw\fast\windows\x86\bin;%PATH% && rm test.txt
	 * cd "./test path" && PATH=C:\abi\paw\fast\windows\x86\bin;%PATH% && rm test.txt */
	{ "-x" },
	{ "--start" },
	/* As --start but debug paths prefixed before release paths */
	{ "-g" },
	{ "--debug" },
	/* As --start but with paths for timed variants prefixed before release
	 * paths  */
	{ "-t" },
	{ "--timed" },
	{ NULL }
};

Edit: Just realised the example I gave in the comment for -x & --start was not clear enough with what it would do so I added in a few lines under the initial command indicating roughly what would happen once the initial command was given

Thought of another option:

Code:

	/* If PAW_SUPER is not defined then look for these in this order:
	 * pkexec, gksu, sudo, su */
	{ "super", optionSuperCBCB },

Pain in the ass to identify which one is available every time you just want to launch under root permissions so just hide it under a wrapper option in a common app, the user can provide the environment variable if needed. Would like to know if there are any alternatives to those commands, particularly pkexec & gksu which provided the popup to get the password when missing a terminal window. Yet to investigate the windows means of doing similar so links to what I should look into would be appreciated there, I'll put the fallback of fiddling with permissions etc on a back burner since it's unlikely that would be unable to launch at all, if anyone's on ubuntu does admin://ls work at all? Would like to put that as the default instead of pkexec to avoid the vulnerability crap, considering searching for the executables and implementing support for it in the command passed to paw, such as paw --x admin://ls, just need to know how to go about enabling that behaviour when those executables aren't available

I'm guessing either no-one had any ideas or simply didn't care, knowing my luck probably the latta

Originally Posted by awsdert

I'm guessing either no-one had any ideas or simply didn't care, knowing my luck probably the latta

Just in case my assumption is wrong I'd thought I'd point out that I'm still open to suggestions on what options to add, this is intended to be a catch all solution for both user & developers after all so it would really help if you point out what common problems you encounter in development and what solutions you usually employ to deal with them, who knows maybe something can be made part of paw's standard options to save you the hassle of employing those solutions every time. For the time being this is where I'm now out in the build process (not asking for help with the errors, I currently have no need of help with those, just gotta get round to actually fixing them):

Code:

make paw (in directory: /mnt/MEDIA/HOME/gitlab/dragonbuilder)
...
/usr/bin/ld: paw.o: in function `exec':
paw.c:(.text+0x8e3): undefined reference to `pawS_expandf'
/usr/bin/ld: paw.o:(.data.rel+0x18): undefined reference to `optionOfAbiCB'
/usr/bin/ld: paw.o:(.data.rel+0x28): undefined reference to `optionOfAbiCB'
/usr/bin/ld: paw.o:(.data.rel+0x38): undefined reference to `optionOfAbiCB'
collect2: error: ld returned 1 exit status
make: *** [makefile:29: paw] Error 1
Compilation failed.

For anyone wandering why I haven't uploaded a link for a compilable version of my app for feedback on what could be / needs to be done for widespread adoption yet, I managed to get my favourite game responding to my controller again so I'll probably be slacking off for the next few months, salem this is one of the few times I'm happy for you to lock the thread since the next time I bring up paw options will be with a completed build. The current issue I need to resolve though is just the 1st build vs subsequent builds, since the 1st build is needed for deciding which directories to put subsequent builds in but I also want the 1st build to go into the default subdirectory in release/debug/timed builds, the default subdirectory being " _+_+cc" making it easier to statically link the minimal functions of the paw library needed to determine which directory should be selected at any given time (e.g. windows 64bit binaries vs 32bit binaries when launching from an "On The Go" directory)

Originally Posted by kodax

Why are you going through such pain,
Given the fact that people will reject your work.
Even folks like us, who go through the same thing, don't care.

Unless there is serious financial compensation which I doubt,
we have limited time..

The point is to SAVE time, rather than trying to directly manage the different builds for different architectures & systems it's easier to setup for a single subsystem, have that work across the board where the subsystem is installed and then start tailoring to the native system based on what APIs that subsystem has detected for you, the beauty of the PATH variable etc is that you can have that subsystem to focus on 1st then attach whatever libs from the native system you want if you want to provide more native support. For example instead of the ABI issues libc currently deals with there could just be a libc built directly in the paw directories that gets linked instead of the system one if the user has installed such one for their home/otg directories, furthermore the package manager can be given a plugin to prompt the user to decide if they want a fully native install (which needs root/admin permissions) or just a local or otg install which needs no such permissions and gives them the option of preserving their installs across distro swaps etc, flatpak etc can then just be given filler binaries that launch the paw versions of the app under the hood, and for the icing on the cake, no permanent (semi or not) damage is done to their system unlike what a fully native install could do by messing with existing binaries, for example could have both gtk & plasma installed without either annoying the other since there will be options for just plain localising libs per app (like flatpak, snaps, windows etc do).

Originally Posted by kodax

Why are you going through such pain,
Given the fact that people will reject your work.
Even folks like us, who go through the same thing, don't care.

Unless there is serious financial compensation which I doubt,
we have limited time..

Thought of another reason for paw to exist, let's say you've found a program, library etc that you want to install but you know or think it might cause issues, with paw you can create & switch to a test user account, install to that user's ~/.paw/* directories and try running it without it effecting the /* directories which are harder to recover from an error in, if it works in ~/.paw/* then you can just install it to your existing user accounts ~/.paw/* and delete the temporary account, finally the install target will not need root permissions if it's installing to the developer's ~/.paw/* directories which takes away the pain of using sudo etc every time just to test your projects in installed mode, by following the /* paths as closely as possible in a subsystem the project's behaviour in those circumstances can be seen better without risking creating issues that are hard / time consuming to recover from.

The major goal of paw is to shift the initial development paradigm from "native 1st then cross-platform / cross-distro" and "all then usr then otg" to "cross-platform / cross-distro 1st then native" and "otg then usr then all" , that's also why I'm trying to develop a library independent of libc/msvcrt, developers will still be free to hook the native stuff normally, rather paw will neither try nor be able to stop that, they just won't have to manage system & cpu builds anymore as paw would be fully responsible for that (outside of their source code)