xnedit icon indicating copy to clipboard operation
xnedit copied to clipboard

AppImage cross-distro Linux package

Open efa opened this issue 2 years ago • 13 comments

please create an AppImage binary cross-distro Linux package. It is very easy, I can help if you are interested

efa avatar Mar 16 '23 21:03 efa

I will look into this. I was planning to publish binary packages for future releases and AppImage seems like a good addition.

unixwork avatar Mar 18 '23 09:03 unixwork

Yes it will help a lot to populate the xnedit :)

yannnnnnnnnnnnnnnn avatar Jun 26 '23 07:06 yannnnnnnnnnnnnnnn

will try to create one for XNEdit and document it with a script

efa avatar Jun 26 '23 08:06 efa

I just tested a bash script "makeAppDir.sh" that generate the AppImage for both 64 and 32 bit Linux. It is callable via shell or by makefile with parameters like: $ makeAppDir.sh XNEdit source/xnedit resources/desktop Linux [32|64] On a Debian 10 64-bit with current git sources it generate a file named: XNEdit-00add27-x86_64.AppImage that should work on any recent distribution.

Attached as .zip as github refuse AppImage attach in comments: XNEdit-00add27-x86_64.AppImage.zip Will test on Debian12 64 bit Please test it at least on Debian, RedHat, Arch, better to generate and test on 32-bit too.

NOTE: I added Debian Multiarch support to my old Debian 10 64-bit server, so it support i386 to cross-build and test. I still cannot generate and test 32 bit AppImage for the following limitations:

  • I have no 32 bit OS anymore, maybe will use a Debian 32-bit VM
  • cannot cross-build from a 64 bit OS to 32 bit target with current XNEdit Makefiles
  • WSL/Win10 do not support FUSE (needed for AppImage), neither 64-bit

Is it OK to put the script in a new directory "resources/appImage"?

efa avatar Jun 27 '23 09:06 efa

Yes, it would be nice to have the script in the repository, resources/AppImage is ok.

unixwork avatar Jun 27 '23 17:06 unixwork

done https://github.com/unixwork/xnedit/pull/110

efa avatar Jun 27 '23 21:06 efa

about 32 bit binaries, as most today OS are 64 bit, become difficult natively generate a 32-bit version. Would you modify the Makefiles to cross-build from a 64-bit OS to 32-bit target?

efa avatar Jun 28 '23 11:06 efa

got feedback from a friend that without "." in PATH, the AppImage won't work. It is related to the fact "linuxdeploy" (wrongly) link xnc instead of xnedit as main binary (with -e xnedit as argument too). I made a workaround modification to the script, manual creating the link to xnedit binary, please check if this still work: https://github.com/efa/xnedit/releases/download/draft/XNEdit-d276ec5-x86_64.AppImage

efa avatar Jun 29 '23 14:06 efa

Yes the image works (tested on Fedora 38).

Regarding the 32 bit, I don't think it is really important. What makefile modifications should I do?

unixwork avatar Jul 01 '23 13:07 unixwork

OK, thanks for test. Will do a new PR for the patched script. Anyway I opened an issue on linuxdeploy: https://github.com/linuxdeploy/linuxdeploy/issues/250

About 32 bit, not much, mainly add -m32 to compile options, and then link the 32 bit version of the library. This last step imply you must have them in your system. In Debian using multiarch I can install a package for Intel x86 with ":i386" trail in its name to install the 32 bit version (and deps), I do now know how is done on RedHat. As example you can compare those two Makefiles for a my app in GTK where the right pkg-config resolve the right libs: https://github.com/efa/ReSolve/blob/main/src/Makefile # native compile https://github.com/efa/ReSolve/blob/main/src/Makefile32 # crossbuild from 64 bit host to 32 bit target up to you if you want still support 32 bit, I expect some fixup in the code may be needed.

efa avatar Jul 01 '23 16:07 efa

done in https://github.com/unixwork/xnedit/pull/113

New AppImage is this attached: XNEdit-dc428d6-x86_64.AppImage.tar.gz This is made on Debian 10 64 bit, so should work on all distro from 2019 to today

efa avatar Jul 02 '23 20:07 efa

Thanks. I will try to create the script to create an AppImage myself soon.

XNEdit works well on 32 bit platforms. The problem is, the old nedit build system is not very flexible. It is designed in a way, that people should just manually modify the platform specific makefile, if they have to make any changes to compiler/linker flags. And I don't think, I should add a special 32 bit linux makefile.

unixwork avatar Jul 03 '23 18:07 unixwork

I confirm XNEdit built for Win32/Cygwin32 work well, but I do not looked at warning at compile time.

if I understood correctly how the nested Makefile system works, the main Makefile through the ".DEFAULT" target creates the link to makefiles/Makefile.[targetPlatform] in Microline/XmL, Xlt, util, and source directories. Then Makefile.[targetPlatform] is executed in the util, Xlt, Microline and finally in source directories. In every Makefile.[targetPlatform] there is an include to file "Makefile.common" for util, Xlt, Microline directories. This in turn includes the respective "Makefile.dependencies"

Instead I didn't understand how "Makefile.depend" should works, I think it should generate a new Makefile.depdendencies" automatically based on include "source/*.h", but give error.

I find it very elegant and versatile for the many supported platforms, even if it is very cryptic for those who don't know Makefiles syntax very well (mine included). Even it support only native build and not cross-build. Anyway I can generate the makefiles/Makefile.cygwin easily looking at templates.

Is it the same system as Nedit or is it new to XNEdit ?

efa avatar Jul 04 '23 09:07 efa