[ptxdist] policy for shared or static libs in ptxdist?

[ptxdist] policy for shared or static libs in ptxdist?

[Alexander Dahl]

Hei everyone,

for a C library project built with CMake, which I'm currently the 
maintainer for, I got some patches from the buildroot folks to support 
static linking of the library. AFAIK buildroot supports building the 
whole BSP statically linked. For CMake based projects it sets the global 
CMake variable BUILD_SHARED_LIBS to control if a package should be built 
as shared or static lib (which of course must be supported by the 
upstream packages then).

As far as ptxdist is concerned, I used grep today to find out how this 
is handled over here. What I could see was no central support for either 
the one or the other, but letting the packages do what they want, each 
handling it individually. However I saw most packages (most are 
autotools based) setting --enable-shared and --disable-static – so I 
assume the general policy for ptxdist is to build shared libraries and 
there's no support for building static libraries, except for some rare 
packages, where a menu option for this exists.

So what I want to know is how this is handled or should be handled in 
ptxdist? Depending on that I maybe will send a patch for building CMake 
based (library) packages.

Greets
Alex


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] policy for shared or static libs in ptxdist?

[Robert Schwebel]

On Tue, Sep 12, 2017 at 10:57:17AM +0200, Alexander Dahl wrote:
> Hei everyone,
> 
> for a C library project built with CMake, which I'm currently the 
> maintainer for, I got some patches from the buildroot folks to support 
> static linking of the library. AFAIK buildroot supports building the 
> whole BSP statically linked. For CMake based projects it sets the global 
> CMake variable BUILD_SHARED_LIBS to control if a package should be built 
> as shared or static lib (which of course must be supported by the 
> upstream packages then).
> 
> As far as ptxdist is concerned, I used grep today to find out how this 
> is handled over here. What I could see was no central support for either 
> the one or the other, but letting the packages do what they want, each 
> handling it individually. However I saw most packages (most are 
> autotools based) setting --enable-shared and --disable-static – so I 
> assume the general policy for ptxdist is to build shared libraries and 
> there's no support for building static libraries, except for some rare 
> packages, where a menu option for this exists.

I'm sharing your point of view.
 
> So what I want to know is how this is handled or should be handled in 
> ptxdist? Depending on that I maybe will send a patch for building CMake 
> based (library) packages.

Make static library handling possible on the library level, but use
shared for the ptxdist make file.

If we might have a clear usecase in the future, we might want to
introduce a global mechanism for that. The closer a single library to
the "standard" way of doing things is, the better.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] policy for shared or static libs in ptxdist?

[Alexander Dahl]

Hello,

Am Mittwoch, 13. September 2017, 07:54:51 schrieb Robert Schwebel:
> > So what I want to know is how this is handled or should be handled
> > in
> > ptxdist? Depending on that I maybe will send a patch for building
> > CMake based (library) packages.
> 
> Make static library handling possible on the library level, but use
> shared for the ptxdist make file.

Sounds reasonable for both sides.

> If we might have a clear usecase in the future, we might want to
> introduce a global mechanism for that. The closer a single library to
> the "standard" way of doing things is, the better.

I thought a little more about how we could handle this for CMake based 
packages. I think hardcoding BUILD_SHARED_LIBS into $(CROSS_CMAKE_USR) 
would be bad, before someone introduced such a global mechanism. FWIW, I 
also don't see such a usecase for static only libs at the moment.

However thanks for your point of view, I will prefer shared libs in 
package receipts for now.

Greets
Alex


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de