On Wed, 3 Jun 2015, Diego Biurrun wrote:
On Tue, May 12, 2015 at 01:24:40PM +0300, Martin Storsjö wrote:
On Tue, 12 May 2015, Diego Biurrun wrote:
>On Tue, May 12, 2015 at 12:34:25AM +0200, Luca Barbato wrote:
>>On 11/05/15 23:09, Diego Biurrun wrote:
>>>On Wed, May 06, 2015 at 01:37:31PM +0200, Luca Barbato wrote:
>>>>Useful to have `make config` work with custom pkgconf path.
>>>>---
>>>> configure | 6 ++++++
>>>> 1 file changed, 6 insertions(+)
>>>
>>>Foo=value1 BAR=value2 /path/to/configure ...
>>
>>See the patch comment. the idea is to provide a mean to configure once
>>and then just do make config to reconfigure.
>
>This will only work if you happen to reconfigure inside the same shell
>where the exports still exist.
I'm not sure what you're trying to say here - yes, if you don't do things as
in this patch, you'd need to set up the variables again. With this patch,
the configure parameters that are saved in config.mak, which are reused in
"make config", would persist this environment assuming that the user (me)
would use it for setting them.
>This is a brittle hack and should be done outside of configure.
Hack? Yes, maybe - also convenient. Brittle in which way?
For starters, what happens if no env is provided? What's with
quoting?
You mean that the actual implementation of the patch isn't perfect yet -
yes, one such issue was fixed - is there anything else concrete that you
notice?
>Just run a short shell script that sets up your environment as you need
>it.
That's what I do today, but Luca suggested this to ease my (and apparently
his) workflow.
When you have literally dozens of different configurations, all with
potentially different buildroots, I prefer libs which are detected via plain
cflags/ldflags over pkg-config, because for cflags/ldflags I can set
--extra-cflags=-I/some/build/root/include etc, and when I need to
reconfigure, I just do "make config".
With pkg-config, I need to run the right shell script to set up
PKG_CONFIG_LIBDIR/PKG_CONFIG_PATH for this particular configuration, which
is one step more than when relying solely on configure parameters (such as
--extra-cflags) that are brought in automatically when doing "make config".
No need to run the right shell script, just do something like
#!/bin/sh
case $(pwd) in
/path/to/repo1)
[snip]
My point wasn't so much about having to run the _right_ script, but about
having to run _a_ script (for the cases where I don't need to add things
to $PATH).
When I need to retest one specific configuration, my workflow normally is
"cd libav-fooconfig; make -jX", which might fail since it needs to
reconfigure. If it failed for such a reason, I run "make config". And this
fails since I had forgotten to source the env script, which I only need
while running configure, not while building, and only in the
configurations where I use external libs that use pkg-config.
For the cases where I need to add things to $PATH, I can't do make without
it, so in those cases it really isn't an issue. It's just to allow
encapsulating the environment that configure needs for running, to allow
rerunning "make config" without any extra setup.
Yes, it's one single step extra, and I'm not dead set on having this - I
just want to see what the concrete points were, in your criticism of the
patch.
To this, Luca investigated and noted that pkg-config lacks a command line
parameter that does the equivalent of setting PKG_CONFIG_LIBDIR/PATH, so it
really has to be set via the environment (otherwise it could be brought in
via --pkg-config-flags). By allowing preserving the extra environment
variables that need to be set while configuring in a configure parameter, it
can all be rerun via a plain "make config", which would simplify my workflow
a little bit. Yes, it's not much, running a shell script is no huge task,
but when it's something you do often, it would reduce the burden.
For cases where I need to add some particular cross-env's bin dir to $PATH,
I would still need to keep using a env setup shellscript (because the
suggested configure parameter would only work within configure, not within
make), but it would at least save me some work in some setups.
So you need to run the shell script anyway. Just extend it.
No, that's not what I said. I said that for the cases where I need to add
things to $PATH it's a non-issue. For the cases where I don't need to add
anything to $PATH, I want to be able to encapsulate the PKG_CONFIG_* env
variables, since "make config" so very elegantly does this for all the
other parameters already (much more elegantly than autotools, where I'd
love to have the same "make config" feature as libav has).
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
