* [Buildroot] Who calls to the defined function/s
@ 2012-11-20 2:21 John Tobias
2012-11-20 8:59 ` Thomas Petazzoni
0 siblings, 1 reply; 6+ messages in thread
From: John Tobias @ 2012-11-20 2:21 UTC (permalink / raw)
To: buildroot
Hi Guys,
I was trying to (fully) understand the dataflow of the buildroot's
Makefile. How/who parse/calls to the functions like:
HELLO_INSTALL_TARGET_CMDS
HELLO_BUILD_CMDS
$(eval $(generic-package))
So, How I can tell to the generic-package to call HELLO_TEST_CMDS too?
example:
define HELLO_TEST_CMDS
...
endef
Regards,
john
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Who calls to the defined function/s
2012-11-20 2:21 [Buildroot] Who calls to the defined function/s John Tobias
@ 2012-11-20 8:59 ` Thomas Petazzoni
2012-11-20 18:26 ` John Tobias
0 siblings, 1 reply; 6+ messages in thread
From: Thomas Petazzoni @ 2012-11-20 8:59 UTC (permalink / raw)
To: buildroot
Dear John Tobias,
On Mon, 19 Nov 2012 18:21:03 -0800, John Tobias wrote:
> I was trying to (fully) understand the dataflow of the buildroot's
> Makefile. How/who parse/calls to the functions like:
>
> HELLO_INSTALL_TARGET_CMDS
> HELLO_BUILD_CMDS
>
> $(eval $(generic-package))
The generic-package macro will find in which directory your Makefile
is, for example package/hello/. It will take this "hello" convert it to
uppercase, and use it as the prefix for all variables. So basically, a
package in package/hello/hello.mk will have to define HELLO_SITE,
HELLO_SOURCE, HELLO_VERSION, and possibly HELLO_BUILD_CMDS,
HELLO_INSTALL_TARGET_CMDS, etc.
> So, How I can tell to the generic-package to call HELLO_TEST_CMDS too?
>
> example:
> define HELLO_TEST_CMDS
> ...
> endef
That would require a modification of the package infrastructure, which
you probably don't want to do. What are you trying to achieve with a
new command exactly?
New commands are normally not needed:
*) For autotools-package and cmake-package, you have hooks so that you
can do something after extraction, after patching, after
configuration, after installation, etc.
*) For generic-package, you can do something like:
ifeq ($(BR2_PACKAGE_HELLO_SOMETHING),y)
define HELLO_DO_THIS_CMDS
$(MAKE) -C $(@D) do-this
endef
endif
ifeq ($(BR2_PACKAGE_HELLO_SOMETHING_ELSE),y)
define HELLO_DO_THAT_CMDS
$(MAKE) -C $(@D) do-that
endef
endif
define HELLO_BUILD_CMDS
$(HELLO_DO_THIS_CMDS)
$(HELLO_DO_THAT_CMDS)
endef
Please make sure to read our documentation at
http://buildroot.org/downloads/manual/manual.html#_adding_new_packages_to_buildroot
which explains all of this with quite some details and examples.
Do not hesitate to get back to the list if you need further details,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Who calls to the defined function/s
2012-11-20 8:59 ` Thomas Petazzoni
@ 2012-11-20 18:26 ` John Tobias
2012-11-20 23:00 ` John Tobias
2012-11-21 6:39 ` Arnout Vandecappelle
0 siblings, 2 replies; 6+ messages in thread
From: John Tobias @ 2012-11-20 18:26 UTC (permalink / raw)
To: buildroot
Dear Thomas Petazzoni,
Thank you for the response. I was thinking to support the package
management in the buildroot. Where, if I define XXX_CREATE_PACKAGE in
my hello.mk
the buildroot (for example) will create an opkg file (off-course I
have supply the necessary information to create the package file).
I know the buildroot community did not support it package management
but I would like to add some flexibility on my buildroot environment.
Regards,
john
On Tue, Nov 20, 2012 at 12:59 AM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Dear John Tobias,
>
> On Mon, 19 Nov 2012 18:21:03 -0800, John Tobias wrote:
>
>> I was trying to (fully) understand the dataflow of the buildroot's
>> Makefile. How/who parse/calls to the functions like:
>>
>> HELLO_INSTALL_TARGET_CMDS
>> HELLO_BUILD_CMDS
>>
>> $(eval $(generic-package))
>
> The generic-package macro will find in which directory your Makefile
> is, for example package/hello/. It will take this "hello" convert it to
> uppercase, and use it as the prefix for all variables. So basically, a
> package in package/hello/hello.mk will have to define HELLO_SITE,
> HELLO_SOURCE, HELLO_VERSION, and possibly HELLO_BUILD_CMDS,
> HELLO_INSTALL_TARGET_CMDS, etc.
>
>> So, How I can tell to the generic-package to call HELLO_TEST_CMDS too?
>>
>> example:
>> define HELLO_TEST_CMDS
>> ...
>> endef
>
> That would require a modification of the package infrastructure, which
> you probably don't want to do. What are you trying to achieve with a
> new command exactly?
>
> New commands are normally not needed:
>
> *) For autotools-package and cmake-package, you have hooks so that you
> can do something after extraction, after patching, after
> configuration, after installation, etc.
>
> *) For generic-package, you can do something like:
>
> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING),y)
> define HELLO_DO_THIS_CMDS
> $(MAKE) -C $(@D) do-this
> endef
> endif
>
> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING_ELSE),y)
> define HELLO_DO_THAT_CMDS
> $(MAKE) -C $(@D) do-that
> endef
> endif
>
> define HELLO_BUILD_CMDS
> $(HELLO_DO_THIS_CMDS)
> $(HELLO_DO_THAT_CMDS)
> endef
>
> Please make sure to read our documentation at
> http://buildroot.org/downloads/manual/manual.html#_adding_new_packages_to_buildroot
> which explains all of this with quite some details and examples.
>
> Do not hesitate to get back to the list if you need further details,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Who calls to the defined function/s
2012-11-20 18:26 ` John Tobias
@ 2012-11-20 23:00 ` John Tobias
2012-11-21 0:52 ` John Tobias
2012-11-21 6:39 ` Arnout Vandecappelle
1 sibling, 1 reply; 6+ messages in thread
From: John Tobias @ 2012-11-20 23:00 UTC (permalink / raw)
To: buildroot
Hi Thomas,
I added some function in generic-package (snapshot of added function):
$(BUILD_DIR)/%/.stamp_create_package:
@$(call MESSAGE,"Creating package")
$(Q)touch $@
In buildroot directory, when I issue a command:
make hello-create-package, it calls the said function. But, since the
new function didn't know by the buildroot, I cannot do the make hello
then the buildroot will call the create-package.
The question is what environment variable should I modify in order the
buildroot should call the create-package too?
Regards,
john
On Tue, Nov 20, 2012 at 10:26 AM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Dear Thomas Petazzoni,
>
> Thank you for the response. I was thinking to support the package
> management in the buildroot. Where, if I define XXX_CREATE_PACKAGE in
> my hello.mk
> the buildroot (for example) will create an opkg file (off-course I
> have supply the necessary information to create the package file).
>
> I know the buildroot community did not support it package management
> but I would like to add some flexibility on my buildroot environment.
>
> Regards,
>
> john
>
> On Tue, Nov 20, 2012 at 12:59 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Dear John Tobias,
>>
>> On Mon, 19 Nov 2012 18:21:03 -0800, John Tobias wrote:
>>
>>> I was trying to (fully) understand the dataflow of the buildroot's
>>> Makefile. How/who parse/calls to the functions like:
>>>
>>> HELLO_INSTALL_TARGET_CMDS
>>> HELLO_BUILD_CMDS
>>>
>>> $(eval $(generic-package))
>>
>> The generic-package macro will find in which directory your Makefile
>> is, for example package/hello/. It will take this "hello" convert it to
>> uppercase, and use it as the prefix for all variables. So basically, a
>> package in package/hello/hello.mk will have to define HELLO_SITE,
>> HELLO_SOURCE, HELLO_VERSION, and possibly HELLO_BUILD_CMDS,
>> HELLO_INSTALL_TARGET_CMDS, etc.
>>
>>> So, How I can tell to the generic-package to call HELLO_TEST_CMDS too?
>>>
>>> example:
>>> define HELLO_TEST_CMDS
>>> ...
>>> endef
>>
>> That would require a modification of the package infrastructure, which
>> you probably don't want to do. What are you trying to achieve with a
>> new command exactly?
>>
>> New commands are normally not needed:
>>
>> *) For autotools-package and cmake-package, you have hooks so that you
>> can do something after extraction, after patching, after
>> configuration, after installation, etc.
>>
>> *) For generic-package, you can do something like:
>>
>> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING),y)
>> define HELLO_DO_THIS_CMDS
>> $(MAKE) -C $(@D) do-this
>> endef
>> endif
>>
>> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING_ELSE),y)
>> define HELLO_DO_THAT_CMDS
>> $(MAKE) -C $(@D) do-that
>> endef
>> endif
>>
>> define HELLO_BUILD_CMDS
>> $(HELLO_DO_THIS_CMDS)
>> $(HELLO_DO_THAT_CMDS)
>> endef
>>
>> Please make sure to read our documentation at
>> http://buildroot.org/downloads/manual/manual.html#_adding_new_packages_to_buildroot
>> which explains all of this with quite some details and examples.
>>
>> Do not hesitate to get back to the list if you need further details,
>>
>> Thomas
>> --
>> Thomas Petazzoni, Free Electrons
>> Kernel, drivers, real-time and embedded Linux
>> development, consulting, training and support.
>> http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Who calls to the defined function/s
2012-11-20 23:00 ` John Tobias
@ 2012-11-21 0:52 ` John Tobias
0 siblings, 0 replies; 6+ messages in thread
From: John Tobias @ 2012-11-21 0:52 UTC (permalink / raw)
To: buildroot
Hi Thomas,
I found where to add the function.
Regards,
john
On Tue, Nov 20, 2012 at 3:00 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hi Thomas,
>
> I added some function in generic-package (snapshot of added function):
>
> $(BUILD_DIR)/%/.stamp_create_package:
> @$(call MESSAGE,"Creating package")
> $(Q)touch $@
>
>
> In buildroot directory, when I issue a command:
>
> make hello-create-package, it calls the said function. But, since the
> new function didn't know by the buildroot, I cannot do the make hello
> then the buildroot will call the create-package.
>
> The question is what environment variable should I modify in order the
> buildroot should call the create-package too?
>
> Regards,
>
> john
>
> On Tue, Nov 20, 2012 at 10:26 AM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Dear Thomas Petazzoni,
>>
>> Thank you for the response. I was thinking to support the package
>> management in the buildroot. Where, if I define XXX_CREATE_PACKAGE in
>> my hello.mk
>> the buildroot (for example) will create an opkg file (off-course I
>> have supply the necessary information to create the package file).
>>
>> I know the buildroot community did not support it package management
>> but I would like to add some flexibility on my buildroot environment.
>>
>> Regards,
>>
>> john
>>
>> On Tue, Nov 20, 2012 at 12:59 AM, Thomas Petazzoni
>> <thomas.petazzoni@free-electrons.com> wrote:
>>> Dear John Tobias,
>>>
>>> On Mon, 19 Nov 2012 18:21:03 -0800, John Tobias wrote:
>>>
>>>> I was trying to (fully) understand the dataflow of the buildroot's
>>>> Makefile. How/who parse/calls to the functions like:
>>>>
>>>> HELLO_INSTALL_TARGET_CMDS
>>>> HELLO_BUILD_CMDS
>>>>
>>>> $(eval $(generic-package))
>>>
>>> The generic-package macro will find in which directory your Makefile
>>> is, for example package/hello/. It will take this "hello" convert it to
>>> uppercase, and use it as the prefix for all variables. So basically, a
>>> package in package/hello/hello.mk will have to define HELLO_SITE,
>>> HELLO_SOURCE, HELLO_VERSION, and possibly HELLO_BUILD_CMDS,
>>> HELLO_INSTALL_TARGET_CMDS, etc.
>>>
>>>> So, How I can tell to the generic-package to call HELLO_TEST_CMDS too?
>>>>
>>>> example:
>>>> define HELLO_TEST_CMDS
>>>> ...
>>>> endef
>>>
>>> That would require a modification of the package infrastructure, which
>>> you probably don't want to do. What are you trying to achieve with a
>>> new command exactly?
>>>
>>> New commands are normally not needed:
>>>
>>> *) For autotools-package and cmake-package, you have hooks so that you
>>> can do something after extraction, after patching, after
>>> configuration, after installation, etc.
>>>
>>> *) For generic-package, you can do something like:
>>>
>>> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING),y)
>>> define HELLO_DO_THIS_CMDS
>>> $(MAKE) -C $(@D) do-this
>>> endef
>>> endif
>>>
>>> ifeq ($(BR2_PACKAGE_HELLO_SOMETHING_ELSE),y)
>>> define HELLO_DO_THAT_CMDS
>>> $(MAKE) -C $(@D) do-that
>>> endef
>>> endif
>>>
>>> define HELLO_BUILD_CMDS
>>> $(HELLO_DO_THIS_CMDS)
>>> $(HELLO_DO_THAT_CMDS)
>>> endef
>>>
>>> Please make sure to read our documentation at
>>> http://buildroot.org/downloads/manual/manual.html#_adding_new_packages_to_buildroot
>>> which explains all of this with quite some details and examples.
>>>
>>> Do not hesitate to get back to the list if you need further details,
>>>
>>> Thomas
>>> --
>>> Thomas Petazzoni, Free Electrons
>>> Kernel, drivers, real-time and embedded Linux
>>> development, consulting, training and support.
>>> http://free-electrons.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Buildroot] Who calls to the defined function/s
2012-11-20 18:26 ` John Tobias
2012-11-20 23:00 ` John Tobias
@ 2012-11-21 6:39 ` Arnout Vandecappelle
1 sibling, 0 replies; 6+ messages in thread
From: Arnout Vandecappelle @ 2012-11-21 6:39 UTC (permalink / raw)
To: buildroot
On 20/11/12 19:26, John Tobias wrote:
> I was thinking to support the package
> management in the buildroot. Where, if I define XXX_CREATE_PACKAGE in
> my hello.mk
> the buildroot (for example) will create an opkg file (off-course I
> have supply the necessary information to create the package file).
>
> I know the buildroot community did not support it package management
> but I would like to add some flexibility on my buildroot environment.
Even though it's very likely that we will not include support for packages in
buildroot, it's worthwhile to post your patches to the list. That way, anybody
else that needs it can pick it up. In addition, you may get some review comments
which are useful for yourself.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
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: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-11-21 6:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-11-20 2:21 [Buildroot] Who calls to the defined function/s John Tobias
2012-11-20 8:59 ` Thomas Petazzoni
2012-11-20 18:26 ` John Tobias
2012-11-20 23:00 ` John Tobias
2012-11-21 0:52 ` John Tobias
2012-11-21 6:39 ` Arnout Vandecappelle
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox