using a variable within a buildroot menuconfig

Hi all,

I have another /weird/ question.

I would like to know if it is possible to create an item in configuration which will for example contain some (absolute) path on my filesystem. Then I would like to use this variable for example in --extra-cflags configure option for applications like ffmpeg etc.

I know that it is not very nice way, but I need to integrate buildroot with Texas Instruments SDK, which is not very GNU build tools friendy.

best regards
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130625/2a4f55c8/attachment.html>

I'm afraid that I don't understand your question. string type
configuration variables can contain any kind of string, including paths of files. This is used for instance in BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE.

Specifically for ffmpeg, however, there is already the
BR2_PACKAGE_FFMPEG_EXTRACONF option. You can just set that to --extra-cflags '-fPIC -DMY_DEFINE' (note the funky quoting, which I'm not 100% sure will work correctly).

I wonder what you mean with the TI SDK. You probably mean you have to
use _some packages_ that are in the 700MB self-extractor, right? Because the SDK itself is in fact a replacement for buildroot (or buildroot is a replacement for the SDK, depending on how you want to look at it :-).

Getting that stuff to work is absolute horror, I can testify. I did
that a year and a half ago for the DM365 multimedia codecs, but I never found a reasonable solution to extract and build individual packages.

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:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

Hi,

Arnout> I wonder what you mean with the TI SDK. You probably mean you have to Arnout> use _some packages_ that are in the 700MB self-extractor, right? Arnout> Because the SDK itself is in fact a replacement for buildroot (or Arnout> buildroot is a replacement for the SDK, depending on how you want to Arnout> look at it :-).

Arnout> Getting that stuff to work is absolute horror, I can testify. I did Arnout> that a year and a half ago for the DM365 multimedia codecs, but I Arnout> never found a reasonable solution to extract and build individual Arnout> packages.

FYI, I'm currently looking at more-or-less the same horror, E.G. the 1.6G ezsdk blob for ti81xx.

Bye, Peter Korsgaard

I too am a victim of the ti81xx EZSDK horror. I've been compiling the
EZSDK on its own, doing a "make install EXEC_DIR=/some/place", and then
using a script to selectively pull stuff out of the created install tree
into something like a target skeleton overlay that gets installed into
staging as well. It works, but stinks for source control. (Check in the
whole 1.6G, most of which is worthless and takes a long time to compile, or
check in the resulting overlay, which feels hacky?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130629/76c47d20/attachment.html>

Danomi> On Thu, Jun 27, 2013 at 8:25 AM, Peter Korsgaard?<[email protected]>?wrote:
Danomi> FYI, I'm currently looking at more-or-less the same horror, E.G. the
Danomi> 1.6G ezsdk blob for ti81xx.

Danomi> I too am a victim of the ti81xx EZSDK horror. ?I've been Danomi> compiling the EZSDK on its own, doing a "make install Danomi> EXEC_DIR=/some/place", and then using a script to selectively Danomi> pull stuff out of the created install tree into something like Danomi> a target skeleton overlay that gets installed into staging as Danomi> well. ?It works, but stinks for source control. ?(Check in the Danomi> whole 1.6G, most of which is worthless and takes a long time to Danomi> compile, or check in the resulting overlay, which feels hacky?)

Yeah, I would like to be able to clean it up enough to get it added to mainline Buildroot, but I've only now started looking..

Bye, Peter Korsgaard

Dear Jan Pohanka,

I'm not sure to really understand what you want to do here. You can always create string options:

config BR2_SOME_PATH
string
default "/path/to/somewhere/"

and then in some .mk file, you can use:

	$(BR2_SOME_PATH)

to refer to still variable, or:

	$(call qstrip,$(BR2_SOME_PATH))

if you want to get rid of the quotes around the variable value.

Does this answer your questions?

Best regards,

Thomas

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