Skip to contentSkip to conversation

ola: new package

PATCH New Dave Skok 2 participants 5 messages Aug 12, 2013 – Aug 15, 2013 1 message not in the archive

lore
Share & tools
lore

Dave Skok

author
#0 lore raw

PATCH 1/1 ola: new package

---
 package/Config.in     |   1 +
 package/ola/Config.in | 144 +++++++++++++++++++++++++++++++++++++++++++++++
 package/ola/ola.mk    | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 298 insertions(+)
 create mode 100644 package/ola/Config.in
 create mode 100644 package/ola/ola.mk
package/Config.in +1 -0
index 7069d77..fb52411 100644
@@ -277,6 +277,7 @@ source "package/minicom/Config.in"
 source "package/nanocom/Config.in"
 source "package/neard/Config.in"
 source "package/ofono/Config.in"
+source "package/ola/Config.in"
 source "package/on2-8170-modules/Config.in"
 source "package/open2300/Config.in"
 source "package/openocd/Config.in"
package/ola/Config.in new file +144 -0

144 lines not on this page · raw message

package/ola/ola.mk new file +153 -0

153 lines not on this page · raw message

Signature · 1 line
1.8.3.4
#1 lore raw

PATCH 1/1 ola: new package

Dear Dave Skok,

Quoted 8 lines · Dave Skok
---
 package/Config.in     |   1 +
 package/ola/Config.in | 144 +++++++++++++++++++++++++++++++++++++++++++++++
 package/ola/ola.mk    | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 298 insertions(+)
 create mode 100644 package/ola/Config.in
 create mode 100644 package/ola/ola.mk

Thanks, it now builds successfully.

However, I've found another issue: even if I keep most plugins disabled, they are still all built and installed. For example, with a configuration that has:

# BR2_PACKAGE_OLA_PLUGIN_KARATE is not set

I get the karate plugin built and installed:

$ ls -1 output/target/usr/lib/olad/*karate*
output/target/usr/lib/olad/libolakarate.so
output/target/usr/lib/olad/libolakarate.so.0
output/target/usr/lib/olad/libolakarate.so.0.0.0

Same goes for:

# BR2_PACKAGE_OLA_PLUGIN_SPI is not set

$ ls -1 output/target/usr/lib/olad/*spi*
output/target/usr/lib/olad/libolaspicore.so
output/target/usr/lib/olad/libolaspicore.so.0
output/target/usr/lib/olad/libolaspicore.so.0.0.0
output/target/usr/lib/olad/libolaspi.so
output/target/usr/lib/olad/libolaspi.so.0
output/target/usr/lib/olad/libolaspi.so.0.0.0

Is this expected?

Thanks,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
author
#2 lore raw

PATCH 1/1 ola: new package

Hi Thomas,

No, plugins should not be built if not selected. I took out autoreconfig when I switched from git repo to tarred release. It is possible that is the cause. I will check.

Dave

Quoted 49 lines · Thomas Petazzoni

Dear Dave Skok,

Quoted 8 lines · Dave Skok

---

package/Config.in     |   1 +
package/ola/Config.in | 144 +++++++++++++++++++++++++++++++++++++++++++++++
package/ola/ola.mk    | 153 ++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 298 insertions(+)

create mode 100644 package/ola/Config.in
create mode 100644 package/ola/ola.mk

Thanks, it now builds successfully.

However, I've found another issue: even if I keep most plugins disabled, they are still all built and installed. For example, with a configuration that has:

# BR2_PACKAGE_OLA_PLUGIN_KARATE is not set

I get the karate plugin built and installed:

$ ls -1 output/target/usr/lib/olad/*karate*
output/target/usr/lib/olad/libolakarate.so
output/target/usr/lib/olad/libolakarate.so.0
output/target/usr/lib/olad/libolakarate.so.0.0.0

Same goes for:

# BR2_PACKAGE_OLA_PLUGIN_SPI is not set

$ ls -1 output/target/usr/lib/olad/*spi*
output/target/usr/lib/olad/libolaspicore.so
output/target/usr/lib/olad/libolaspicore.so.0
output/target/usr/lib/olad/libolaspicore.so.0.0.0
output/target/usr/lib/olad/libolaspi.so
output/target/usr/lib/olad/libolaspi.so.0
output/target/usr/lib/olad/libolaspi.so.0.0.0

Is this expected?

Thanks,

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

A message that is not in the archive (sent off-list or not yet received): CALy4uEU8nED=gPosezp_5dK79BQ8Q18ZtogJhPComrO+kHkJZA@mail.gmail.com

author
#4 lore raw

PATCH 1/1 ola: new package

Hi Thomas,

I checked with maintainer and karate and spi plugins build by mistake even with --disable to configure. Will have to either live with that or take selection out and user assumes that it will be built. The milinst plugin is new and I added it to the list as well as ordered all alphabetically.
Also found error with a plug in requiring python dependency in original
patch and added python binding dependency comment for said plugin.

A general buildroot question...
When plugin selections added after first build, ./configure is not re-run.
As such dependencies are built but not new plugins. Is there something I
need to put in package patch to make this work?

I realize that the .stamp_configured needs to be deleted and if selections are added this works fine. If selections removed the already built pieces will remain in staging and target. Am I right?

Dave

Quoted 14 lines · Blanco

Hi Thomas,

No, plugins should not be built if not selected. I took out autoreconfig when I switched from git repo to tarred release. It is possible that is the cause. I will check.

Dave

Quoted 2 lines · Thomas Petazzoni

Dear Dave Skok,

Quoted 50 lines
Quoted 5 lines · Dave Skok
Quoted 4 lines

---
package/Config.in | 1 +
package/ola/Config.in | 144

+++++++++++++++++++++++++++++++++++++++++++++++

Quoted 1 line
Quoted 1 line

package/ola/ola.mk | 153

++++++++++++++++++++++++++++++++++++++++++++++++++

Quoted 41 lines
Quoted 3 lines
3 files changed, 298 insertions(+)

create mode 100644 package/ola/Config.in
create mode 100644 package/ola/ola.mk

Thanks, it now builds successfully.

However, I've found another issue: even if I keep most plugins disabled, they are still all built and installed. For example, with a configuration that has:

# BR2_PACKAGE_OLA_PLUGIN_KARATE is not set

I get the karate plugin built and installed:

$ ls -1 output/target/usr/lib/olad/*karate*
output/target/usr/lib/olad/libolakarate.so
output/target/usr/lib/olad/libolakarate.so.0
output/target/usr/lib/olad/libolakarate.so.0.0.0

Same goes for:

# BR2_PACKAGE_OLA_PLUGIN_SPI is not set

$ ls -1 output/target/usr/lib/olad/*spi*
output/target/usr/lib/olad/libolaspicore.so
output/target/usr/lib/olad/libolaspicore.so.0
output/target/usr/lib/olad/libolaspicore.so.0.0.0
output/target/usr/lib/olad/libolaspi.so
output/target/usr/lib/olad/libolaspi.so.0
output/target/usr/lib/olad/libolaspi.so.0.0.0

Is this expected?

Thanks,

Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130815/e3053949/attachment.html>

#5 lore raw

PATCH 1/1 ola: new package

Dear David Skok,

Quoted 3 lines · David Skok

I checked with maintainer and karate and spi plugins build by mistake even with --disable to configure. Will have to either live with that or take selection out and user assumes that it will be built.

Ok, then for now, remove the options for those plugins that are always built, and only add options for plugins that can actually be disabled/enabled.

Quoted 9 lines

The milinst plugin
is new and I added it to the list as well as ordered all alphabetically.
Also found error with a plug in requiring python dependency in original
patch and added python binding dependency comment for said plugin.

A general buildroot question...
When plugin selections added after first build, ./configure is not re-run.
As such dependencies are built but not new plugins. Is there something I
need to put in package patch to make this work?

No, because we don't try to make this work. When an user changes the Buildroot configuration, he has either to rebuild everything, or to know what are the impacts of the configuration change and rebuild the corresponding packages.

The problem is that it is almost impossible to know what is the impact of an arbitrary change in the configuration, so we don't try to handle this, it's part of the KISS principle.

Thomas

Signature · 4 lines
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com