All of lore.kernel.org
 help / color / mirror / Atom feed
* [Buildroot] [PATCH 1/1] new package: jsen
@ 2016-02-16  6:48 Atul Singh
  2016-02-16 21:25 ` Thomas Petazzoni
  0 siblings, 1 reply; 5+ messages in thread
From: Atul Singh @ 2016-02-16  6:48 UTC (permalink / raw)
  To: buildroot

JSEN (JSON Sentinel) validates your JSON objects using JSON-Schema.

Signed-off-by: Atul Singh <atul.singh.mandla@rockwellcollins.com>
---
 package/Config.in      |  1 +
 package/jsen/Config.in |  6 ++++++
 package/jsen/jsen.hash |  2 ++
 package/jsen/jsen.mk   | 32 ++++++++++++++++++++++++++++++++
 4 files changed, 41 insertions(+)
 create mode 100644 package/jsen/Config.in
 create mode 100644 package/jsen/jsen.hash
 create mode 100644 package/jsen/jsen.mk

diff --git a/package/Config.in b/package/Config.in
index a5b31aa..cb3a3c8 100644
--- a/package/Config.in
+++ b/package/Config.in
@@ -994,6 +994,7 @@ menu "JSON/XML"
 	source "package/expat/Config.in"
 	source "package/ezxml/Config.in"
 	source "package/jansson/Config.in"
+	source "package/jsen/Config.in"
 	source "package/json-c/Config.in"
 	source "package/json-glib/Config.in"
 	source "package/jsoncpp/Config.in"
diff --git a/package/jsen/Config.in b/package/jsen/Config.in
new file mode 100644
index 0000000..8c41a19
--- /dev/null
+++ b/package/jsen/Config.in
@@ -0,0 +1,6 @@
+config BR2_PACKAGE_JSEN
+	bool "jsen"
+	help
+	  JSEN (JSON Sentinel) validates your JSON objects using JSON-Schema.
+
+	  https://github.com/bugventure/jsen
diff --git a/package/jsen/jsen.hash b/package/jsen/jsen.hash
new file mode 100644
index 0000000..fdfcd93
--- /dev/null
+++ b/package/jsen/jsen.hash
@@ -0,0 +1,2 @@
+# Locally Computed
+sha256  651b3ae5c92865705c144175a8297305788a0e9a1f46ee9b8caa127c6bce6709  jsen-v0.6.0.tar.gz
diff --git a/package/jsen/jsen.mk b/package/jsen/jsen.mk
new file mode 100644
index 0000000..e939739
--- /dev/null
+++ b/package/jsen/jsen.mk
@@ -0,0 +1,32 @@
+################################################################################
+#
+# jsen
+#
+################################################################################
+
+JSEN_VERSION = v0.6.0
+JSEN_SITE = $(call github,bugventure,jsen,$(JSEN_VERSION))
+JSEN_LICENSE = MIT
+JSEN_LICENSE_FILES = LICENSE
+JSEN_DIRECTORIES_LIST = dist lib
+JSEN_ROOT_FILES_LIST = index.js
+
+define JSEN_INSTALL_TARGET_CMDS
+	# Install required directories
+	for dir in $(JSEN_DIRECTORIES_LIST); \
+	do \
+		$(INSTALL) -d $(TARGET_DIR)/usr/share/jsen/$$dir && \
+		$(INSTALL) -m 0644 -t $(TARGET_DIR)/usr/share/jsen/$$dir \
+			$(@D)/$$dir/*.* || exit 1; \
+	done
+
+	# Install required files from the root directory
+	for file in $(JSEN_ROOT_FILES_LIST); \
+	do \
+		$(INSTALL) -D -m 0644 $(@D)/$$file \
+			$(TARGET_DIR)/usr/share/jsen/$$file \
+			|| exit 1; \
+	done
+endef
+
+$(eval $(generic-package))
-- 
2.5.0

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [Buildroot] [PATCH 1/1] new package: jsen
  2016-02-16  6:48 [Buildroot] [PATCH 1/1] new package: jsen Atul Singh
@ 2016-02-16 21:25 ` Thomas Petazzoni
  2016-02-16 21:34   ` Yegor Yefremov
  2016-02-16 23:33   ` [Buildroot] copy-package infrastructure [was: Re: [PATCH 1/1] new package: jsen] Arnout Vandecappelle
  0 siblings, 2 replies; 5+ messages in thread
From: Thomas Petazzoni @ 2016-02-16 21:25 UTC (permalink / raw)
  To: buildroot

Atul,

Thanks also for this contribution. As usual, a few comments.

First, the title should be:

	jsen: new package

As per our convention for naming the commits for new packages.

On Tue, 16 Feb 2016 12:18:13 +0530, Atul Singh wrote:

> diff --git a/package/Config.in b/package/Config.in
> index a5b31aa..cb3a3c8 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -994,6 +994,7 @@ menu "JSON/XML"
>  	source "package/expat/Config.in"
>  	source "package/ezxml/Config.in"
>  	source "package/jansson/Config.in"
> +	source "package/jsen/Config.in"
>  	source "package/json-c/Config.in"
>  	source "package/json-glib/Config.in"
>  	source "package/jsoncpp/Config.in"

I am not sure JSON/XML is the appropriate place. Yes, jsen is related
to JSON, but I believe its main characteristic is that it is a
Javascript library. So it should probably go under the Javascript menu,
where we already have another package named json-javascript.

Yegor, what do you think? If the number of Javascript libraries becomes
really huge, then we can start creating sub-categories. But it is too
early to do this now.

> diff --git a/package/jsen/jsen.mk b/package/jsen/jsen.mk
> new file mode 100644
> index 0000000..e939739
> --- /dev/null
> +++ b/package/jsen/jsen.mk
> @@ -0,0 +1,32 @@
> +################################################################################
> +#
> +# jsen
> +#
> +################################################################################
> +
> +JSEN_VERSION = v0.6.0
> +JSEN_SITE = $(call github,bugventure,jsen,$(JSEN_VERSION))
> +JSEN_LICENSE = MIT
> +JSEN_LICENSE_FILES = LICENSE
> +JSEN_DIRECTORIES_LIST = dist lib
> +JSEN_ROOT_FILES_LIST = index.js
> +
> +define JSEN_INSTALL_TARGET_CMDS
> +	# Install required directories
> +	for dir in $(JSEN_DIRECTORIES_LIST); \
> +	do \
> +		$(INSTALL) -d $(TARGET_DIR)/usr/share/jsen/$$dir && \
> +		$(INSTALL) -m 0644 -t $(TARGET_DIR)/usr/share/jsen/$$dir \
> +			$(@D)/$$dir/*.* || exit 1; \
> +	done
> +
> +	# Install required files from the root directory
> +	for file in $(JSEN_ROOT_FILES_LIST); \
> +	do \
> +		$(INSTALL) -D -m 0644 $(@D)/$$file \
> +			$(TARGET_DIR)/usr/share/jsen/$$file \
> +			|| exit 1; \
> +	done
> +endef

I think this is more complicated than it needs to be. What about:

define JSEN_INSTALL_TARGET_CMDS
	mkdir -p $(TARGET_DIR)/usr/share/jsen
	$(foreach d,dist lib index.js,\
		cp -dpfr $(@D)/$(d) $(TARGET_DIR)/usr/share/jsen/$(sep))
endef

As a side note, I am wondering if we shouldn't create some common
infrastructure to simplify all those packages that just need to "copy"
stuff. Either a special variable in the generic-package infrastructure,
or a separate "copy-package" infrastructure that provides a special
variable that allows the package to list "stuff to be copied" and
another listing "where to copy". But that's clearly beyond the scope of
your patch, so don't worry about this.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] [PATCH 1/1] new package: jsen
  2016-02-16 21:25 ` Thomas Petazzoni
@ 2016-02-16 21:34   ` Yegor Yefremov
  2016-02-16 23:33   ` [Buildroot] copy-package infrastructure [was: Re: [PATCH 1/1] new package: jsen] Arnout Vandecappelle
  1 sibling, 0 replies; 5+ messages in thread
From: Yegor Yefremov @ 2016-02-16 21:34 UTC (permalink / raw)
  To: buildroot

Atul, Thomas,

On Tue, Feb 16, 2016 at 10:25 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Atul,
>
> Thanks also for this contribution. As usual, a few comments.
>
> First, the title should be:
>
>         jsen: new package
>
> As per our convention for naming the commits for new packages.
>
> On Tue, 16 Feb 2016 12:18:13 +0530, Atul Singh wrote:
>
>> diff --git a/package/Config.in b/package/Config.in
>> index a5b31aa..cb3a3c8 100644
>> --- a/package/Config.in
>> +++ b/package/Config.in
>> @@ -994,6 +994,7 @@ menu "JSON/XML"
>>       source "package/expat/Config.in"
>>       source "package/ezxml/Config.in"
>>       source "package/jansson/Config.in"
>> +     source "package/jsen/Config.in"
>>       source "package/json-c/Config.in"
>>       source "package/json-glib/Config.in"
>>       source "package/jsoncpp/Config.in"
>
> I am not sure JSON/XML is the appropriate place. Yes, jsen is related
> to JSON, but I believe its main characteristic is that it is a
> Javascript library. So it should probably go under the Javascript menu,
> where we already have another package named json-javascript.
>
> Yegor, what do you think? If the number of Javascript libraries becomes
> really huge, then we can start creating sub-categories. But it is too
> early to do this now.

I agree with you, that this package should go to Javascript libraries.

>> diff --git a/package/jsen/jsen.mk b/package/jsen/jsen.mk
>> new file mode 100644
>> index 0000000..e939739
>> --- /dev/null
>> +++ b/package/jsen/jsen.mk
>> @@ -0,0 +1,32 @@
>> +################################################################################
>> +#
>> +# jsen
>> +#
>> +################################################################################
>> +
>> +JSEN_VERSION = v0.6.0
>> +JSEN_SITE = $(call github,bugventure,jsen,$(JSEN_VERSION))
>> +JSEN_LICENSE = MIT
>> +JSEN_LICENSE_FILES = LICENSE
>> +JSEN_DIRECTORIES_LIST = dist lib
>> +JSEN_ROOT_FILES_LIST = index.js
>> +
>> +define JSEN_INSTALL_TARGET_CMDS
>> +     # Install required directories
>> +     for dir in $(JSEN_DIRECTORIES_LIST); \
>> +     do \
>> +             $(INSTALL) -d $(TARGET_DIR)/usr/share/jsen/$$dir && \
>> +             $(INSTALL) -m 0644 -t $(TARGET_DIR)/usr/share/jsen/$$dir \
>> +                     $(@D)/$$dir/*.* || exit 1; \
>> +     done
>> +
>> +     # Install required files from the root directory
>> +     for file in $(JSEN_ROOT_FILES_LIST); \
>> +     do \
>> +             $(INSTALL) -D -m 0644 $(@D)/$$file \
>> +                     $(TARGET_DIR)/usr/share/jsen/$$file \
>> +                     || exit 1; \
>> +     done
>> +endef
>
> I think this is more complicated than it needs to be. What about:
>
> define JSEN_INSTALL_TARGET_CMDS
>         mkdir -p $(TARGET_DIR)/usr/share/jsen
>         $(foreach d,dist lib index.js,\
>                 cp -dpfr $(@D)/$(d) $(TARGET_DIR)/usr/share/jsen/$(sep))
> endef
>
> As a side note, I am wondering if we shouldn't create some common
> infrastructure to simplify all those packages that just need to "copy"
> stuff. Either a special variable in the generic-package infrastructure,
> or a separate "copy-package" infrastructure that provides a special
> variable that allows the package to list "stuff to be copied" and
> another listing "where to copy". But that's clearly beyond the scope of
> your patch, so don't worry about this.
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] copy-package infrastructure [was: Re: [PATCH 1/1] new package: jsen]
  2016-02-16 21:25 ` Thomas Petazzoni
  2016-02-16 21:34   ` Yegor Yefremov
@ 2016-02-16 23:33   ` Arnout Vandecappelle
  2016-02-17  7:55     ` Thomas Petazzoni
  1 sibling, 1 reply; 5+ messages in thread
From: Arnout Vandecappelle @ 2016-02-16 23:33 UTC (permalink / raw)
  To: buildroot

On 16-02-16 22:25, Thomas Petazzoni wrote:
> define JSEN_INSTALL_TARGET_CMDS
> 	mkdir -p $(TARGET_DIR)/usr/share/jsen
> 	$(foreach d,dist lib index.js,\
> 		cp -dpfr $(@D)/$(d) $(TARGET_DIR)/usr/share/jsen/$(sep))
> endef
> 
> As a side note, I am wondering if we shouldn't create some common
> infrastructure to simplify all those packages that just need to "copy"
> stuff. Either a special variable in the generic-package infrastructure,
> or a separate "copy-package" infrastructure that provides a special
> variable that allows the package to list "stuff to be copied" and
> another listing "where to copy". But that's clearly beyond the scope of
> your patch, so don't worry about this.


 It fairly often happens that other stuff is needed as well, so the copy-package
infrastructure doesn't sound like a good idea. A variable is also not so simple,
because you need to specify the source and the target directories.

 So I think it should be a function, like

define JSEN_INSTALL_TARGET_CMDS
	$(call copy-dirs,dist lib index js,/usr/share/jsen)
endef

 However, I think it's not really worth it. We're saving just a little bit of
code, and hiding what's really happening. I prefer to keep things explicit.

 BTW in the same vein, we should also get rid of the github helper. It was
introduced because the github URLs were changing all the time, but that's no
longer the case now.

 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [Buildroot] copy-package infrastructure [was: Re: [PATCH 1/1] new package: jsen]
  2016-02-16 23:33   ` [Buildroot] copy-package infrastructure [was: Re: [PATCH 1/1] new package: jsen] Arnout Vandecappelle
@ 2016-02-17  7:55     ` Thomas Petazzoni
  0 siblings, 0 replies; 5+ messages in thread
From: Thomas Petazzoni @ 2016-02-17  7:55 UTC (permalink / raw)
  To: buildroot

Hello,

On Wed, 17 Feb 2016 00:33:23 +0100, Arnout Vandecappelle wrote:

> > As a side note, I am wondering if we shouldn't create some common
> > infrastructure to simplify all those packages that just need to "copy"
> > stuff. Either a special variable in the generic-package infrastructure,
> > or a separate "copy-package" infrastructure that provides a special
> > variable that allows the package to list "stuff to be copied" and
> > another listing "where to copy". But that's clearly beyond the scope of
> > your patch, so don't worry about this.
> 
> 
>  It fairly often happens that other stuff is needed as well, so the copy-package
> infrastructure doesn't sound like a good idea. A variable is also not so simple,
> because you need to specify the source and the target directories.

Yes, it is indeed common that a few other things need to be done.

>  So I think it should be a function, like
> 
> define JSEN_INSTALL_TARGET_CMDS
> 	$(call copy-dirs,dist lib index js,/usr/share/jsen)
> endef
> 
>  However, I think it's not really worth it. We're saving just a little bit of
> code, and hiding what's really happening. I prefer to keep things explicit.

Yeah, that's an opinion. I don't have a strong opinion either way, but
I can certainly understand the opinion that things should remain
explicit, and to not needlessly introduce new infrastructures.

>  BTW in the same vein, we should also get rid of the github helper. It was
> introduced because the github URLs were changing all the time, but that's no
> longer the case now.

Right. It would make it clearer for anyone reading the code that when
fetching from Github, we're actually doing an http download and not a
git clone.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2016-02-17  7:55 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-16  6:48 [Buildroot] [PATCH 1/1] new package: jsen Atul Singh
2016-02-16 21:25 ` Thomas Petazzoni
2016-02-16 21:34   ` Yegor Yefremov
2016-02-16 23:33   ` [Buildroot] copy-package infrastructure [was: Re: [PATCH 1/1] new package: jsen] Arnout Vandecappelle
2016-02-17  7:55     ` Thomas Petazzoni

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.