remove libpod from main #3419
remove libpod from main #3419
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: baude The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Changes LGTM, but you'll hate me for this, but I HATE, HATE, HATE the config package name. Too generic and you already have a couple of collisions. Perhaps 'podconfig' or 'podcfg' or even 'pconfig'? Just so it likely won't be tromped over by another package in the future. |
|
I do sort of agree that the Maybe |
67c800b to
6c63de6
Compare
|
ok, updated and used 'define' |
|
I'll say LGTM, but let's leave this until after 1.4.3 merges |
the compilation demands of having libpod in main is a burden for the remote client compilations. to combat this, we should move the use of libpod structs, vars, constants, and functions into the adapter code where it will only be compiled by the local client. this should result in cleaner code organization and smaller binaries. it should also help if we ever need to compile the remote client on non-Linux operating systems natively (not cross-compiled). Signed-off-by: baude <bbaude@redhat.com>
6c63de6 to
dd81a44
Compare
|
/hold |
|
LGTM |
|
LGTM, thanks for the rework @baude |
|
and I forgot, a painful but I think will prove to be a very nice change. Thanks for taking it on! |
|
/hold cancel |
the compilation demands of having libpod in main is a burden for the
remote client compilations. to combat this, we should move the use of
libpod structs, vars, constants, and functions into the adapter code
where it will only be compiled by the local client.
this should result in cleaner code organization and smaller binaries. it
should also help if we ever need to compile the remote client on
non-Linux operating systems natively (not cross-compiled).
Signed-off-by: baude bbaude@redhat.com