[ptxdist] dependencies with collections

[ptxdist] dependencies with collections

[Alexander Dahl]

Hei hei, 

to not use a workaround on building our BSP I'd like to have some ideas
on a dependency problem together with collections. We use collections to
have slightly different builds of a BSP on the same target hardware. I
have set PTXCONF_OPENSSL=m so I can activate/deactivate it in a
collection. In one of our make rules (lets say rules/foo.make) there are
the following lines:

279 # install openssl default config
280 ifdef PTXCONF_OPENSSL
281     @$(call install_copy, foo, root, root, 0644, \
282         $(PTXDIST_SYSROOT_TARGET)/usr/lib/ssl/openssl.cnf,
/usr/lib/ssl/openssl.cnf)
283 endif

The openssl package does not install this by default. If I had special
needs for this file I would put it in my projectroot but I don't so the
default which comes with openssl is sufficient.

Now my problem: If I deactivate openssl in my collection, then in
foo.make PTXCONF_OPENSSL still seems to be defined so the install_copy
is executed, but does not find openssl.conf if openssl it was not build
before. Actually it was not (yet?) build in this case because nothing
else depends on it. `ptxdist install openssl` and then `ptxdist go`
leads to installing openssl.conf although I don't need it.

I see two possible solutions at the moment from my point of view:

1) There's a way to test in the make file if openssl is activated in
the collection and I missed it.
2) Someone™ adapts the openssl package to make it possible to choose
between installing the generic openssl.conf or her own copy from
projectroot.
3) The third even more elegant solution I missed.

Any hints on this welcome. O:-)

Greets
Alex

-- 
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains us all
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601  D1D5 8FBA 7744 CC87 10D0 ***

-- 
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] dependencies with collections

[Michael Olbrich]

Hi,

On Thu, Aug 16, 2012 at 03:06:11PM +0200, Alexander Dahl wrote:
> to not use a workaround on building our BSP I'd like to have some ideas
> on a dependency problem together with collections. We use collections to
> have slightly different builds of a BSP on the same target hardware. I
> have set PTXCONF_OPENSSL=m so I can activate/deactivate it in a
> collection. In one of our make rules (lets say rules/foo.make) there are
> the following lines:
> 
> 279 # install openssl default config
> 280 ifdef PTXCONF_OPENSSL
> 281     @$(call install_copy, foo, root, root, 0644, \
> 282         $(PTXDIST_SYSROOT_TARGET)/usr/lib/ssl/openssl.cnf,
> /usr/lib/ssl/openssl.cnf)
> 283 endif
> 
> The openssl package does not install this by default. If I had special
> needs for this file I would put it in my projectroot but I don't so the
> default which comes with openssl is sufficient.
> 
> Now my problem: If I deactivate openssl in my collection, then in
> foo.make PTXCONF_OPENSSL still seems to be defined so the install_copy
> is executed, but does not find openssl.conf if openssl it was not build
> before. Actually it was not (yet?) build in this case because nothing
> else depends on it. `ptxdist install openssl` and then `ptxdist go`
> leads to installing openssl.conf although I don't need it.
> 
> I see two possible solutions at the moment from my point of view:
> 
> 1) There's a way to test in the make file if openssl is activated in
> the collection and I missed it.

ifneq ($(filter openssl,$(PACKAGES)),)
...
endif

I think. I would not recommend this. This will break if you switch
collections without rebuilding everything.
Also, you need to depend on openssl to make sure the file is already
available.

> 2) Someone™ adapts the openssl package to make it possible to choose
> between installing the generic openssl.conf or her own copy from
> projectroot.

install_alternative should looks in pkgdir if nothing is found in
projectroot etc.

> 3) The third even more elegant solution I missed.

Create a separate package that selects openssl and is enabled/disabled with
it on the collectionconfig.

Michael

-- 
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] dependencies with collections

[Alexander Dahl]

Hei Michael, 

Am 2012-08-21 11:32, schrieb Michael Olbrich:
>> 3) The third even more elegant solution I missed.
> 
> Create a separate package that selects openssl and is enabled/disabled with
> it on the collectionconfig.

Im playing around with this solution now. Seems promising and solves
some other minor problems on the way.

Greets
Alex

-- 
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains us all
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601  D1D5 8FBA 7744 CC87 10D0 ***

-- 
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] dependencies with collections

[Alexander Dahl]

Hei hei, 

Am 2012-08-21 11:32, schrieb Michael Olbrich:
>> 1) There's a way to test in the make file if openssl is activated in
>> the collection and I missed it.
> 
> ifneq ($(filter openssl,$(PACKAGES)),)
> ...
> endif
> 
> I think. I would not recommend this. This will break if you switch
> collections without rebuilding everything.
> Also, you need to depend on openssl to make sure the file is already
> available.

A question came to my mind: why is "ifdef PTXCONF_FOO" true in the
first place when FOO=m in the ptxconfig and FOO is not set in the
collectionconfig? If collections are used, why wouldn't you wanna check
the collectionconfig if a package is activated instead of the ptxconfig?

Greets
Alex

-- 
»With the first link, the chain is forged. The first speech censured,
the first thought forbidden, the first freedom denied, chains us all
irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie)
*** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601  D1D5 8FBA 7744 CC87 10D0 ***

-- 
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] dependencies with collections

[Michael Olbrich]

Hi,

On Thu, Aug 30, 2012 at 11:29:25AM +0200, Alexander Dahl wrote:
> Am 2012-08-21 11:32, schrieb Michael Olbrich:
> >> 1) There's a way to test in the make file if openssl is activated in
> >> the collection and I missed it.
> > 
> > ifneq ($(filter openssl,$(PACKAGES)),)
> > ...
> > endif
> > 
> > I think. I would not recommend this. This will break if you switch
> > collections without rebuilding everything.
> > Also, you need to depend on openssl to make sure the file is already
> > available.
> 
> A question came to my mind: why is "ifdef PTXCONF_FOO" true in the
> first place when FOO=m in the ptxconfig and FOO is not set in the
> collectionconfig? If collections are used, why wouldn't you wanna check
> the collectionconfig if a package is activated instead of the ptxconfig?

Well historically the answer is, because it's easier and should make no
difference. ptxconfig and collectionconfig are just sourced into the
Makefile.

'ifdef PTXCONF_FOO' is to setup variables etc. and
'PACKAGES-$(PTXCONF_FOO) += foo' is to enable the package. In any generic
code this is important, because there are platform specific packages that
cannot be built, even with 'PTXCONF_FOO=y'.

I had a patch at some point, that removed any PTXCONF_FOO=m lines when
working with collections. I never applied it because there was no real
benefit.

Also, creating multiple images from different collectionconfigs in one go
is on my todo list. I'm not quite sure how to implement this, but it's
quite possible that the concept of one list with all packages to built will
go away at some point. There will only be
'can be built' == 'ifdef PTXCONF_FOO'
or
'is built' == 'something depends on install/targetinstall'

Michael

-- 
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