Closed SelfRef closed 1 year ago
Thanks a lot for your effort on this - I will review it and sort out a merge as soon as I get time to do so. :grin:
I am actively looking at this, I think it highlights a few issues with the current build process I'm going to tidy up and update this a bit. I have #192 open I want to look at resolving so that like the packaging between Arch/Debian remain in sync.
@SelfRef I haven't tested it 100% yet but I believe I have a buildall.sh
script working for Debian - I'm wondering is this feasible for Arch Linux/AUR?
The gist of it is two scripts: bldnpkg.sh
that builds and packages one single component, and buildall.sh
which reads a list of components to build and calls bldnpkg.sh
for each one.
bldnpkg.sh
and the CMakeLists are changed so they can accept an option to use locally built libraries rather than system ones for the libs in this project. buildall.sh
will ensure that the libs that are required are built first so they can be linked against. This should allow compilation and packaging of all components in one hit, instead of needing to ensure libs are compiled/installed manually in the right order.
I still need to implement dependency mapping for the package output (so gtk3
maps to libgtk-3-0
on Debian, and whatever it is on Arch). The other thing is probably having some verification script to identify build time dependencies so its possible to gather the names of all packages you need installed to compile everything.
@SelfRef I haven't tested it 100% yet but I believe I have a
buildall.sh
script working for Debian - I'm wondering is this feasible for Arch Linux/AUR?
For now PKGBUILD contains a modified cmake
and make
commands from Debian build script but this requires to maintain build commands in two separate places.
An ideal solution would be to have a separate scripts for build.sh
and for package.sh
components because the build script alone could be then reused and called in PKGBUILD for Arch without additional tweaks.
That was what I was hoping to do... in a sense to get the full build working for that issue (to solve the issue of compiling everything in one go), and then support the build/package stuff separately once I resume this PR so I can test on Arch. :grin:
Closing in on this - I just need to test #192 as I believe I have the implementation complete. There are now build.sh
, and <format>/package.sh
scripts for those phases alongside buildall.sh
which takes the list of components.
Going to see if I can get this integrated now
@SelfRef
Haven't fully tested as I need to go to bed really, but I think I have got it working now
This is under the feat-archpkg
branch if you want to test it out for yourself. I do need to tidy package.sh
as the archpkg/deb scripts are very copy-paste, but that's about it.
I had a look over what you did here and aimed to sort of 'massage' it into the build changes I did for #192 - if you want to have a look over and let me know if it's okay or whether it's too bodge-y or anything it would be much appreciated.
Also whilst I didn't directly merge the PR (because of the build change stuff) - please let me know if you'd be happy to add you as co author or something on the commit or add some credit somewhere!
This is under the
feat-archpkg
branch if you want to test it out for yourself. I do need to tidypackage.sh
as the archpkg/deb scripts are very copy-paste, but that's about it.
Cool, I've just tested your scripts. I'm now using distrobox
for such cases, even on native Arch to test everything in "pure" environment and this is what I noticed:
chkdeps.sh
could also check tool deps by command name in pure bash like if ! type python3 > /dev/null; then...
buildall.sh
works in unexpected way, README says "build script for compiling all components in the project" so just like build.sh
but for all component, however this script is also creating packages which may not be what someone wanted; a better description and/or flag to skip packaging would be great.comgtk
if failing and I'm not sure why:
Packaged wintc-theme-luna-blue
buildall: Building shell/run
buildall: Building shared/comgtk
-- The C compiler identification is GNU 13.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/sbin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake/Modules/FindPkgConfig.cmake:99 (find_package_handle_standard_args)
/home/tm/Projects/xfce-winxp-tc/packaging/cmake-inc/linking/CMakeLists.txt:3 (find_package)
CMakeLists.txt:20 (include)
-- Configuring incomplete, errors occurred! make: *** No targets specified and no makefile found. Stop. Failed build for shared/comgtk buildall: Compile failure, bailing.
> Also whilst I didn't directly merge the PR (because of the build change stuff) - please let me know if you'd be happy to add you as co author or something on the commit or add some credit somewhere!
I think the best would be to update main README's installation section and mention that this project is also in AUR at [xfce-winxp-tc-git](https://aur.archlinux.org/packages/xfce-winxp-tc-git) and it's maintained by me. This is what most Arch users will be looking for when seeing this project and by that it'll gain some popularity :)
Now I'm just going to rewrite AUR's PKGBUILD to use these new build scripts and as soon as they'll be working fine and merged to `master` I'll drop update to AUR.
Thanks for having a look
chkdeps.sh could also check tool deps by command name in pure bash like if ! type python3 > /dev/null; then...
It could test if they exist, but part of what the Python script does is map them to packages per distro... I figured perhaps it was okay to leave the 'fundamental' stuff out (eg. make
) since they're either expected or normally preinstalled already.
buildall.sh works in unexpected way, README says "build script for compiling all components in the project" so just like build.sh but for all component, however this script is also creating packages which may not be what someone wanted; a better description and/or flag to skip packaging would be great.
Noted. I'll update the README
and support an option to skip packaging.
building shared libraries like comgtk if failing and I'm not sure why:
Looks like pkgconfig
is missing? Seemed to already be installed for me on Arch...
I think the best would be to update main README's installation section and mention that this project is also in AUR at xfce-winxp-tc-git and it's maintained by me. This is what most Arch users will be looking for when seeing this project and by that it'll gain some popularity :)
Now I'm just going to rewrite AUR's PKGBUILD to use these new build scripts and as soon as they'll be working fine and merged to master I'll drop update to AUR.
Will do - just doing some tidying, and will implement your suggestions before merging to master
. :grin:
@SelfRef All done and merged. There is also now -z
switch for buildall.sh
to skip packaging steps.
Thanks very much for your help and advice!
Looks like
pkgconfig
is missing? Seemed to already be installed for me on Arch...
Aaaand... yes, this was the issue. I forgot to install base-devel
meta-package that pulls dev tools. If you've installed Arch via archinstall
command then it's already there.
It could test if they exist, but part of what the Python script does is map them to packages per distro... I figured perhaps it was okay to leave the 'fundamental' stuff out (eg.
make
) since they're either expected or normally preinstalled already.
I mean, yeah, you're right and this was just minor suggestion as I see you like to make your scripts very automated and fool-proof. In case of Arch Linux there would be requirements for base-devel
(meta package) + cmake
+ python
. Only the last one I wouldn't take for granted as most lightweight distros like Arch and Alpine don't install it by default.
I see buildall.sh
just finished without any issues and all packages were built! Great work! :tada:
I might integrate those suggestions in #198 :thinking: :memo:
EDIT: Also yeah that makes sense, I did use archinstall
to set it up initially (never used Arch before working on this soo :sweat_smile: )
These are changes that add support for new build type
archpkg
inCMakeLists.txt
files to remove workarounds while packaging this project for Arch Linux. Additionally inpackaging/
directory there iscomponents.build
list that contains all components and can be used to fine tune build process to include only intended components. This file can be used by other build scripts as well. It does contain only component list without shared libraries as they are required dependency for final package and are always built.Additionally there is
PKGBUILD
file included which is created in the way it's possible to build all components using local repository or directly through AUR. A helper script and instructions are also included inarchpkg/
directory. I also found a nice way to build this packages from inside other distributions using Distrobox - it's explained inarchpkg/README.md
.In comparison to previous
PKGBUILD
I've created this is a split package which means it builds many final package files. Currently I separated shared libraries from the rest of components so this version creates bothlibwintc-git
andxfce-winxp-tc-git
packages and the second one has requirement for first one (although they can be installed together at once). I think it's more convenient in comparison to creating two separatePKGBUILD
's because then they couldn't be built and installed at one.I think about splitting components for even more packages and then creating meta-package to be able to install them at once but I have doubts anyone would like to use e.g. icons without theme or vice versa and it's much more easier to maintain one package instead of ten. Nevertheless I'm open for suggestions.
After merging this changes I'll be able to upload the new
PKGBUILD
to AUR so they will be in sync.I think this PR resolves #182
Tested on virtual machine: