On 06/11/2013 08:41 AM, Andrea Adami wrote:
On Tue, Jun 11, 2013 at 4:22 PM, Saul Wold <s...@linux.intel.com> wrote:
On 06/11/2013 07:14 AM, Andrea Adami wrote:
ping
Maybe you want cramfs in recipes-devtools and not in recipes-support?
Feedback, please
Apologies, we will not accept this recipe being moved into oe-core, there is
not a strong case to move it to oe-core, cramfs is a image
type that is not heavily used, and the recipe is available in meta-oe.
Saul,
See... the 'not heavily used' is always relative: there are still
many devices out in the wild with cramfs 'firmwares'.
This along with other filesystem related items, such as the FUSE
discussion should be moved into a meta-filesystems layer within
meta-openembedded similar to the way that meta-networking is structured.
You're missing my first point: I/we aim to have as less layer
interdependency as possible (oe-core + BSP) so having to add meta-oe
is just an unneeded burden for most cases.
Oh, and it would be one recipe less in that meta-oe pot.
By refactoring it as a layer within meta-openembedded would also not
make it "one more recipe" in OE-Core. It will be not as heavy as the
meta-oe. OE-core can't test and maintain everything, again relative usage.
Your right it should move someplace, but not into OE-Core.
Sau!
Thx for your review
Cheers
Andrea
Sau!
Andrea
On Tue, Jun 4, 2013 at 1:51 PM, Andrea Adami <andrea.ad...@gmail.com>
wrote:
Note there would be also the possibility to use the mkfs.cramfs
provided by util-linux implementing changes in image_types.bbclass and
util-linux itself.
Seems a bit overkill to me but still an option...
Andrea
On Tue, Jun 4, 2013 at 1:39 PM, Andrea Adami <andrea.ad...@gmail.com>
wrote:
ping
Recipe is rather stable (tarball of v.1.1 dated 2002) and cramfs can
be handy for read-only images on legacy devices.
All the needed infrastructure is already present in
image_types.bbclass so I'd say this recipe has been mistakenly
forgotten when splitting out oe-core
Andrea
On Sun, May 26, 2013 at 1:23 AM, Andrea Adami <andrea.ad...@gmail.com>
wrote:
* though listed in IMAGE_FSTYPES the helper is missing so
* make oe-core autosufficient importing the recipe.
* Fix PN -> BPN to avoid fetch errors with cramfs-native
Signed-off-by: Andrea Adami <andrea.ad...@gmail.com>
---
meta/recipes-support/cramfs/cramfs_1.1.bb | 29
+++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 meta/recipes-support/cramfs/cramfs_1.1.bb
diff --git a/meta/recipes-support/cramfs/cramfs_1.1.bb
b/meta/recipes-support/cramfs/cramfs_1.1.bb
new file mode 100644
index 0000000..0bca0e1
--- /dev/null
+++ b/meta/recipes-support/cramfs/cramfs_1.1.bb
@@ -0,0 +1,29 @@
+DESCRIPTION = "Builds cramfs filesystems for embedded systems"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM =
"file://COPYING;md5=393a5ca445f6965873eca0259a17f833"
+DEPENDS = "zlib"
+
+PE = "1"
+
+SRC_URI =
"http://sourceforge.net/projects/cramfs/files/cramfs/1.1/${BPN}-${PV}.tar.gz";
+
+SRC_URI[md5sum] = "d3912b9f7bf745fbfea68f6a9b9de30f"
+SRC_URI[sha256sum] =
"133caca2c4e7c64106555154ee0ff693f5cf5beb9421ce2eb86baee997d22368"
+
+EXTRA_OEMAKE = "\
+ 'CC=${CC}' \
+ 'CFLAGS=${CFLAGS}' \
+ 'LDFLAGS=${LDFLAGS}' \
+"
+
+do_compile_prepend() {
+ ln -sf GNUmakefile Makefile
+}
+
+do_install() {
+ install -d ${D}${bindir}
+ install mkcramfs ${D}${bindir}
+ install cramfsck ${D}${bindir}
+}
+
+BBCLASSEXTEND = "native"
--
1.8.1.5
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
