History log of /haiku/src/kits/package/solver/Jamfile
Revision Date Author Comments
# ca7a630e 03-Jan-2019 Alexander von Gluck IV <kallisti5@unixzen.com>

kits/package: Break LibsolvSolver add-on out

* BSolver is implemented by solver add-ons
* We may want to (unlikely) leverage another
package solver in the future.
* We may want to (likely) implement a dummy
solver when libsolv is unavailable on new
architectures without bootstrap.
* This also makes solving missing libsolv a little
more graceful vs the "include "libsolv.h" not
found.

Change-Id: Iedd9d0f022fb743c4c7606bd33a4b6dbef0576f7
Reviewed-on: https://review.haiku-os.org/c/haiku/+/819
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>


# cf0ba058 06-Feb-2017 Humdinger <humdingerb@gmail.com>

Add localization to package daemon and solver

Thanks to Adrien and Rene for reviewing and guidance.
Fixes #13282.


# 220d0402 31-Jul-2014 Oliver Tappe <zooey@hirschkaefer.de>

Use libstdc++, libsupc++ and libgcc from gcc_syslibs.

* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.


# c591ff14 05-Aug-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Support building libpackage-add-on-libsolv.so for secondary arch


# a20eb7f4 13-Jun-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Update libsolv package

Also make use of new build feature rules.


# 1a4d020d 02-Apr-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Flesh out the package kit solver API quite a bit more

* Reorganize things a bit:
- BSolver is now an abstract base class.
- A libsolv based implementation, LibsolvSolver, lives in a new
add-on, which is loaded lazily.
- Get rid of libpackage_solver. Save for LibsolvSolver everything
is moved to libpackage.
- This is a nicer solution for the cyclic dependency caused by
libsolv (libsolvext to be precise) using the package kit for
reading repositories and package files.
* Add a solver result data structure and and an accessor the solver.
* Add problem reporting support to the solver. There aren't data
structures for the problem solutions yet and support for selecting
solutions and re-solving is missing as well.


# 479ca816 31-Mar-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Beginnings of the PackageKit dependency solver

Not functional (or tested) yet. The libsolv setup for a somewhat
simplified installation case should be more or less complete, though.
The solution conversion to to-be-created Haiku data structures and the
handling of problems is still missing, though.


# 220d04022750f40f8bac8f01fa551211e28d04f2 31-Jul-2014 Oliver Tappe <zooey@hirschkaefer.de>

Use libstdc++, libsupc++ and libgcc from gcc_syslibs.

* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.


# c591ff14a109d9af2497fcd50886aa867391374c 05-Aug-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Support building libpackage-add-on-libsolv.so for secondary arch


# a20eb7f497fd5789baee973d9f381d155c231951 13-Jun-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Update libsolv package

Also make use of new build feature rules.


# 1a4d020daf80d0b0c30062530cf735ce46dc7dba 02-Apr-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Flesh out the package kit solver API quite a bit more

* Reorganize things a bit:
- BSolver is now an abstract base class.
- A libsolv based implementation, LibsolvSolver, lives in a new
add-on, which is loaded lazily.
- Get rid of libpackage_solver. Save for LibsolvSolver everything
is moved to libpackage.
- This is a nicer solution for the cyclic dependency caused by
libsolv (libsolvext to be precise) using the package kit for
reading repositories and package files.
* Add a solver result data structure and and an accessor the solver.
* Add problem reporting support to the solver. There aren't data
structures for the problem solutions yet and support for selecting
solutions and re-solving is missing as well.


# 479ca8169c85621dda097bebe337bcc373eba68f 31-Mar-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Beginnings of the PackageKit dependency solver

Not functional (or tested) yet. The libsolv setup for a somewhat
simplified installation case should be more or less complete, though.
The solution conversion to to-be-created Haiku data structures and the
handling of problems is still missing, though.