#
8bf87f93 |
|
30-Sep-2013 |
François Revol <revol@free.fr> |
Actually fix the build Looks like I was too quick on previous commit. It seems -pthread is actually not that much needed on Linux though... although the manpage says "compile and link with -pthread". Go figure. Now dlopen() uses RTLD_LAZY | RTLD_LOCAL for Linux, which seems to work here.
|
#
57405de5 |
|
29-Sep-2013 |
Niels Sascha Reedijk <niels.reedijk@gmail.com> |
Always use dlopen and dlsym to load libsolv Previous implementation used weak symbols on all platforms except Haiku. Mac OS X also does not support this use of weak symbols. In the discussion of #10028 it was decided that probably more platforms will have problems with this approach, so instead use the approach that always works.
|
#
6eb7e259 |
|
28-Sep-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
libpackage_build: undefined weak symbols are unsupported ... also for gcc 4 (#8288), so we have to use the dlopen() method always when building on Haiku. Fixes the build on gcc 4 Haiku.
|
#
4dd0ed48 |
|
05-Jul-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
BSolver: fix for gcc 2 Missed one #if, so sCreateSolver was never initialized.
|
#
bd915d9f |
|
05-Jul-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
BSolver: fix build host build for gcc 2 gcc 2 doesn't support the weakref attribute. Rather use the regular (target) method to initialize sCreateSolver instead (pthread once, dlopen()). Since we know that we're on Haiku, that doesn't add any dependencies that aren't available anyway.
|
#
98c6dfa4 |
|
05-Jul-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Switch build system from optional package to repositories * Build libsolv and the dependency solver part of the package kit for the build platform. * Add build tool get_package_dependencies. Given a list of package files and a list of repository files it determines the additional packages that need to be retrieved from the repositories and prints their URLs. * Add rules to work with external repositories in the build system (build/jam/RepositoryRules): - PackageRepository declares an external repository with all its packages. The URL of the repository file isn't specified. It is computed from a given base URL and the SHA256 hash of the list of package files. - GeneratedRepositoryPackageList generates a file containing the file names of all packages in a repository. - IsPackageAvailable returns whether a package is available in any repository. - PackageURL returns the URL for a package. * Declare the HaikuPorts repository for x86_gcc2 (build/jam/repositories/HaikuPorts/x86_gcc2). * Add rule AddHaikuImagePackages to add a package to the image and rule IsHaikuImagePackageAdded to determine whether a package has been added. * OptionalPackages: Remove all entries that just downloaded and installed an external package. AddHaikuImagePackages can be used instead and is used in the remaining entries. Also move the remaining optional package dependency declarations from OptionalPackageDependencies here. * ExtractBuildFeatureArchives: Instead of the URL parameter a package name must be specified now. This allows to simplify BuildFeatures significantly, since there's no dealing with URLs anymore. "if" out the entries that aren't supported yet. * build_haiku_image: For the packages installed in system and common resolve their dependencies and download and install them as well.
|
#
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.
|
#
8bf87f93417aa5ea697a68e409ebea80569bf294 |
|
30-Sep-2013 |
François Revol <revol@free.fr> |
Actually fix the build Looks like I was too quick on previous commit. It seems -pthread is actually not that much needed on Linux though... although the manpage says "compile and link with -pthread". Go figure. Now dlopen() uses RTLD_LAZY | RTLD_LOCAL for Linux, which seems to work here.
|
#
57405de578b6ad646e55435b1b1d286cd5a5a6b3 |
|
29-Sep-2013 |
Niels Sascha Reedijk <niels.reedijk@gmail.com> |
Always use dlopen and dlsym to load libsolv Previous implementation used weak symbols on all platforms except Haiku. Mac OS X also does not support this use of weak symbols. In the discussion of #10028 it was decided that probably more platforms will have problems with this approach, so instead use the approach that always works.
|
#
6eb7e259e9c9dfa1a88cf9cf388c0f3589512531 |
|
28-Sep-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
libpackage_build: undefined weak symbols are unsupported ... also for gcc 4 (#8288), so we have to use the dlopen() method always when building on Haiku. Fixes the build on gcc 4 Haiku.
|
#
4dd0ed48e3dd486d3f2e8c15eeb90466cd5b0229 |
|
05-Jul-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
BSolver: fix for gcc 2 Missed one #if, so sCreateSolver was never initialized.
|
#
bd915d9f53216d1998effadf1d8ef25eafdc67a6 |
|
05-Jul-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
BSolver: fix build host build for gcc 2 gcc 2 doesn't support the weakref attribute. Rather use the regular (target) method to initialize sCreateSolver instead (pthread once, dlopen()). Since we know that we're on Haiku, that doesn't add any dependencies that aren't available anyway.
|
#
98c6dfa41e20c57edf426197a8d9aab6223a59fd |
|
05-Jul-2013 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Switch build system from optional package to repositories * Build libsolv and the dependency solver part of the package kit for the build platform. * Add build tool get_package_dependencies. Given a list of package files and a list of repository files it determines the additional packages that need to be retrieved from the repositories and prints their URLs. * Add rules to work with external repositories in the build system (build/jam/RepositoryRules): - PackageRepository declares an external repository with all its packages. The URL of the repository file isn't specified. It is computed from a given base URL and the SHA256 hash of the list of package files. - GeneratedRepositoryPackageList generates a file containing the file names of all packages in a repository. - IsPackageAvailable returns whether a package is available in any repository. - PackageURL returns the URL for a package. * Declare the HaikuPorts repository for x86_gcc2 (build/jam/repositories/HaikuPorts/x86_gcc2). * Add rule AddHaikuImagePackages to add a package to the image and rule IsHaikuImagePackageAdded to determine whether a package has been added. * OptionalPackages: Remove all entries that just downloaded and installed an external package. AddHaikuImagePackages can be used instead and is used in the remaining entries. Also move the remaining optional package dependency declarations from OptionalPackageDependencies here. * ExtractBuildFeatureArchives: Instead of the URL parameter a package name must be specified now. This allows to simplify BuildFeatures significantly, since there's no dealing with URLs anymore. "if" out the entries that aren't supported yet. * build_haiku_image: For the packages installed in system and common resolve their dependencies and download and install them as well.
|
#
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.
|