tinyx: remove need for autotools

[hovercats]

as mentioned in #73

[apprehensions]

why? these still have to be generated manually via autotools with an update of these packages, and this solution is quite weird.

IMO TinyX should provide a tarball with all of these pre-generated, if not you should make your own generated by github CI.

[hovercats]

why? these still have to be generated manually via autotools with an update of these packages, and this solution is quite weird.

Because alot of people dont like autotools, and Im one of those. No they dont, theyll work just fine regardless of what version of autotools you have installed on your system, aswell as if you dont at all. The only reason to rerun autotools here would be if said autotools have changes which will alter the generation of the files in question. In which case, Ill happily update them.

If however you have a better solution here, Im all ears.

IMO TinyX should provide a tarball with all of these pre-generated, if not you should make your own generated by github CI.

They wont do that, and Im not going to bother asking for it either, when I can just do it myself. Also; how would that make a difference to what ive done here? This is afaik how other projects like procps-ng does it. Project initually needs autotools to generate the configure script. They just prerun the bootstrap script beforehand, then create the tarball. How would using gh ci make a difference here? If gh ci just runs the exact command, and hand you the files, you would have the exact same files as Ive provided here.

[apprehensions]

Because alot of people dont like autotools, and Im one of those

Do you prefer to install autotools to update a single package? Or to have it tarballed by GitHub CI that makes it for you without the need to install autotools on your system? Or save some space in the repository by using autotools?

many packages still rely on automake and autoconf:

./community/community/cava/depends:automake make
./community/community/crispy-doom/depends:automake make
./community/community/crosstool-ng/depends:automake make
./community/community/fdm/depends:automake make
./community/community/jbig2dec/depends:automake make
./community/community/neovim/depends:automake make
./community/community/pmount/depends:automake make
./community/community/powertop/depends:automake            make
./kiss-xorg/community/dillo/depends:automake make
./kiss-xorg/community/fvwm/depends:automake make
./kiss-xorg/community/goffice/depends:automake make
./kiss-xorg/community/mypaint-brushes/depends:automake make
./kiss-xorg/community/x11vnc/depends:automake make
./kiss-xorg/community/xclip/depends:automake make
./kiss-xorg/xorg/tinyx/depends:automake make
./community/community/automake/depends:autoconf
./community/community/crispy-doom/depends:autoconf make
./community/community/gphoto2/depends:autoconf    make
./community/community/jbig2dec/depends:autoconf make
./community/community/powertop/depends:autoconf-archive    make
./kiss-xorg/community/dillo/depends:autoconf make
./kiss-xorg/community/fvwm/depends:autoconf make
./kiss-xorg/community/goffice/depends:autoconf make
./kiss-xorg/community/mypaint-brushes/depends:autoconf make
./kiss-xorg/community/neon/depends:autoconf make
./kiss-xorg/community/schismtracker/depends:autoconf make
./kiss-xorg/community/stalonetray/depends:autoconf make
./kiss-xorg/community/x11vnc/depends:autoconf make
./kiss-xorg/community/xclip/depends:autoconf make
./kiss-xorg/community/xsel/depends:autoconf make
./kiss-xorg/community/xwallpaper/depends:autoconf make
./kiss-xorg/xorg/tinyx/depends:autoconf make
./kiss-xorg/xorg/xf86-video-ati/depends:autoconf make

is automake and autoconf the same as autotools? and what would the difference be made here?

[hovercats]

Because alot of people dont like autotools, and Im one of those

Do you prefer to install autotools to update a single package? Or to have it tarballed by GitHub CI that makes it for you without the need to install autotools on your system? Or save some space in the repository by using autotools?

Id very much prefer not having to deal with autotools at all tbqh. I have never used github ci at all, so I cant speak much for its usecases, but I know others have made github build quite large packages. Space isnt very concerning to me, either on disk or on gh, however, having a repo which is several hundreds of mbs or even gbs would not benefit anyone. In any case, im in favor of w/e has the most benefits; least amount of work for the user and their machines, uses less space etc. Which to me seems to point to using CI.

many packages still rely on automake and autoconf:

I know, and I only use two of them, and one Ive managed to skip using it (tinyx), the other one I have yet to be bothered with. (xsel)

is automake and autoconf the same as autotools? and what would the difference be made here?

Autotools is the general grouping of automake, autoconf and libtool more or less. Most of the time, you need all of the 3 if package is using some bootstrap script or w/e. Theres not much difference. Usually I find that if a package has listed automake or autoconf as dep, it still needs all 3 anyway.

[hovercats]

I was trying to run this on a different system of mine, and it seems configure script complains about missing aclocal (part of automake), so this doesnt fully work yet. Ill look into it, and push a fix for it when I find it.

Also, @ehawkvu, whats your thought on this, or creating a github CI or something?

edit: I made an issue over at tinycorelinux/tinyx#6 in any case I seem to be missing some file, as I can clone the repo, run autogen.sh script, then remove autotools, and run configure/make without issues.

[echawk]

@hovercats - I think it'd be best then to keep using autotools, or for one of us to setup a mirror and a github CI script to make tarballs of each commit - or - we could pre generate the files and have them be on a separate branch that we checkout.

[hovercats]

for now anyway, absolutely stick with autotools, to avoid any problems for other users. I have forked the tinyx project for now, with the intent of seeing if I can figure out how we can bypass it. Heres what ive gathered for now;

run the autogen.sh script ./configure make but cancel right away. (this should generate the file which aclocal is neede for) kiss r automake autoconf libtool make clean, just to be sure built things are removed ./configure make should now build succeccfully, without autotools installed.

However, there seems to be something thats not carried over with the commit. if I commit the newly generated files from running the above command (obviously cleaned, so nothing is prebuilt). now reclone the repo someplace else, and see if we can now build it without autotools present on our system, we get this;

$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/tmp/tinyx/missing' aclocal-1.16
-I m4
/tmp/tinyx/missing[81]: aclocal-1.16: not found
WARNING: 'aclocal-1.16' is missing on your system.
         You should only need it if you modified 'acinclude.m4' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'aclocal' program is part of the GNU Automake package:
         <https://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <https://www.gnu.org/software/autoconf>
         <https://www.gnu.org/software/m4/>
         <https://www.perl.org/>
         make: *** [Makefile:427: aclocal.m4] Error 127

as far as I can see, neither files mentioned is modified afterwards. Im not sure how to proceed pass this point, so if someone else has some idea, Im all ears.

[hovercats]

@ehawkvu can you test to see if this tarball now builds for you, without autotools? I just removed .git and .gitignore, ran autoreconf -v --install. then removed autotools. it seems to build fine on my end anyway. If this works, we can proceed with this PR.

http://0x0.st/Hobk.tar.gz

[hovercats]

ok so @ehawkvu Ive made a release on my tinyx repo (just forked the tiny repo, for this stuff). Ive pushed the changes to reflect this. from my point of view, this is now ready to be merge, but please check to see if this works on your end aswell.

[echawk]

Thank you for working on this!