[Buildroot] [PATCH] pkg-infra: add documentation for <pkg>_CONFIG_FIXUP variable
Stefan Fröberg
stefan.froberg at petroprogram.com
Wed Jan 23 13:19:21 UTC 2013
Hi Samuel
23.1.2013 0:54, Samuel Martin kirjoitti:
> Hi Stefan,
>
> Thanks for your work.
> My comments inlined.
>
> 2013/1/21 Stefan Fröberg <stefan.froberg at petroprogram.com>:
>> Signed-off-by: Stefan Fröberg <stefan.froberg at petroprogram.com>
>> ---
>> docs/manual/adding-packages-generic.txt | 96 ++++++++++++++++++++++--------
>> 1 files changed, 70 insertions(+), 26 deletions(-)
>>
>> diff --git a/docs/manual/adding-packages-generic.txt b/docs/manual/adding-packages-generic.txt
>> index 7b8561a..3b61031 100644
>> --- a/docs/manual/adding-packages-generic.txt
>> +++ b/docs/manual/adding-packages-generic.txt
> [...]
>> +34: define LIBFOO_PERMISSIONS
>> +35: /bin/foo f 4755 0 0 - - - - -
>> +36: endef
>> +37:
>> 37: $(eval $(generic-package))
> s/37/38/
Uups!
>> --------------------------------
>>
>> @@ -69,7 +70,45 @@ install header files and other development files in the staging space.
>> This will ensure that the commands listed in the
>> +LIBFOO_INSTALL_STAGING_CMDS+ variable will be executed.
>>
>> -On line 12, we specify the list of dependencies this package relies
>> +On line 12, we specify that there is some fixing to be done to some
>> +of the 'libfoo-config' files that were installed during
>> ++LIBFOO_INSTALL_STAGING_CMDS+ phase.
>> +These *-config files are executable shell script files that are
>> +located in '$(STAGING_DIR)/usr/bin' directory and are executed
>> +by other 3rd party packages to find out the location and the linking
>> +flags of this particular package.
>> +
>> +The problem is that all these *-config files by default give wrong,
> s/,$//
No $ ? Ok.
>> +host system linking flags that are unsuitable for cross-compiling.
>> +
>> +For example: '-I/usr/include' vs. '-I$(STAGING_DIR)/usr/include'
>> +or: '-L/usr/lib' vs. '-L$(STAGING_DIR)/usr/lib'
> s/vs./instead of/
> imho, it's more obvious than "vs.", but i am not a native English speaker, so...
Then that makes it two of us :-)
>> +
>> +So some sed magic is done to these scripts to make them give correct
>> +flags.
>> +The argument to be given to +LIBFOO_CONFIG_FIXUP+ is the file name(s)
>> +of the shell script(s) needing fixing. All these names are relative to
>> +'$(STAGING_DIR)/usr/bin' and if needed multiple names can be given.
>> +
>> +Example 1:
>> +
>> +Package divine installs shell script '$(STAGING_DIR)/usr/bin/divine-config'.
>> +
>> +So it's fixup would be:
>> +
>> +DIVINE_CONFIG = divine-config
>> +
>> +Example 2:
>> +
>> +Package imagemagick installs the following scripts:
>> +'$(STAGING_DIR)/usr/bin/{Magick,Magick++,MagickCore,MagickWand,Wand}-config'
>> +
>> +So it's fixup would be:
>> +
>> +IMAGEMAGICK_CONFIG_FIXUP = Magick-config Magick++-config \
>> + MagickCore-config MagickWand-config Wand-config
> I really like this digression, it makes clearer how to use the
> *_CONFIG_FIXUP variable.
Thanks!
>> +
>> +On line 13, we specify the list of dependencies this package relies
>> on. These dependencies are listed in terms of lower-case package names,
>> which can be packages for the target (without the +host-+
>> prefix) or packages for the host (with the +host-+) prefix).
>> @@ -240,6 +279,11 @@ information is (assuming the package name is +libfoo+) :
>> variables are executed to install the package into the staging
>> directory.
>>
>> +* +LIBFOO_CONFIG_FIXUP+ lists the names of the files in
>> + '$(STAGING_DIR)/usr/bin' that need some special fixing to make them
>> + cross-compiling friendly. Multiple file names separated by space can be
>> + given and all are relative to '$(STAGING_DIR)/usr/bin'.
>> +
>> * +LIBFOO_INSTALL_TARGET+ can be set to +YES+ (default) or +NO+. If
>> set to +YES+, then the commands in the +LIBFOO_INSTALL_TARGET_CMDS+
>> variables are executed to install the package into the target
>
> Regards,
>
No more typos?
Well, in that case I will fix those three things and resubmit it later
this evening.
Thanks for review Samuel!
Best Regards
Stefan
More information about the buildroot
mailing list