Provide a top-level configure script/Makefile

[emtiu]

Currently, ./configure, make and make install take place separately in the backintime/common and backintime/qt directories of our source tree.

It's good that the CLI and the GUI are two separate "products", but I think building and installing could be a little more comfortable.

I'm thinking we might provide a top-level script/Makefile that allows differentiating like make cli or make gui or just make for both. I'll take a look at doing that, unless there's a better idea or a reason against it.

[buhtz]

This topic is about migrating BIT to modern Python Packaging standards and get rid of "make".

In short: I do have a solution but did not want to come up with to early because it would break the whole BIT development for weeks or months. As longer we wait as more warm we become with the code base what will make a migration easier in the future.

Users will install BIT from source via python3 -m pip install ..
Developers will install it via python3 -m pip install -e .
Distro package maintainers will also use python3 -m pip install . in the back of there distro specific packaging tools.

Make is not a solution and very unusual today in the Python world.

This was one of the first things I investigated in BIT and I did research and tests about possible solutions. One big question influencing which approach we may choose was if and how we keep CLI and GUI separated. In short: I was convinced to treat CLI and GUI as two (technical) separate applications and packages.

To investigate details I used a demo project you can find here https://codeberg.org/buhtz/bit_demo . But the current state of that demo repo does not represent the solution I have in mind.

I don't know if it make sense to discuss about it yet in details. We don't have resources now to migrate the repo. My point here is just that playing around with "make" won't help and just burn ressources.

[buhtz]

I think your point was not about find a better make solution but find a build-test-install-infrastructure integrating our two packages/applications at once?

This won't even be possible with the solution I have in mind. But technically it is possible with Python standard tools and without make. But that latter way would make it impossible for Distro maintainers to offer two separate packages (deb-files).

When it is just about installing: When the users do python3 -m pip install . in the qt folder python will treat common (the CLI) as a dependency and install it automatically.

[emtiu]

All right, that's a good reason for me to leave the configure script and Makefiles alone for the time being :)

[buhtz]

OK, my plan was to come up with a demo project illustrating all technical details and possible pitfalls of my proposal how to migrate the packaging infrastructure.

But before that I see more urgent rsync related Issues. And to handle them I need to investigate and document how BIT and rsync work together. My knowledge about it is very limited.