Those that know me have seen that I am fairly anti-eval where ever possible.

So I am asking for feedback on an alternative I am looking to employ to see if anyone can poke holes in my idea

I have been labouring away to create a package manager on a source based (CLFS) system. One of the issues I have faced is that when some of the
compilations require flags to be set, such as CC or LDFLAGS, I have been dragged into the eval world and used the following:
Now the only reason to use eval here is the CONF_FLAGS array once expanded needs to be
evaluated prior to being used or the command line will consider it to be commands and errors.

My new idea however is to remove the eval and simply sed the CONF_FLAGS into the configure script itself:
So as stated earlier, my questions is this:

Can anyone see any inherent issue with this method?

Or, if anyone has an even better idea I am all ears

Please fire questions about anything that is too unclear

For my Bash build scripts, I prefer to use
Is there a reason why this would not work for you?

For other interested parties: The command is run in a subshell, because then the name=value pairs in CONF_FLAGS array can simply be exported to the environment. I tend to be very careful about variable expansion, so my lists are evaluated per-element ("${var[@]}") to avoid having them be re-split. Finally, if either export or configure fails, the subshell immediately exits with the same exit status, propagating it to the parent process $?.

2 members found this post helpful.

Thank you NA ... valuable information as always I will give it a try. I do like it more than my current suggestion as tampering with the configure was more of a kludge than anything

Well I am guessing by the lack of other replies that NA's solution would be the most optimum that anyone can think of (including me )

Cheers again NA

Actually this just occured to me, the elements in CONF_FLAGS have the form var=value, right? You can pass that to configure directly (see Defining Variables):

Last time I used some packages had weird autoconf macros which would treat configure variables and environment variables differently -- specifically CC and CFLAGS; I think the environment value was appended to the configure variable value or some similar trickery. Also, not all ./configure scripts are autoconf-based; there are a few packages that use a simplified self-written version. This was a few years ago, so things may have changed (it'd take me a while to find even examples).

I'm not saying the subshell+export is the best solution, but it is the one that worked best for me.

Thanks for the input ntubski I guess my query to this method, not having had NA's experiences myself, would be, why then do sites like (C)LFS place the var=value prior to the ./configure?

I guess is it also possible that in some configure scripts they may possibly be interpreted as parameters? (just guessing of course)

Because the shell will place all NAME=VALUE pairs listed before the command into the environment variables for that command.

Most, but not all, ./configure scripts recognize NAME=VALUE pairs, and treat them as variable assignments. In my experience, some scripts are buggy or obscure, and treat the assignments differently to environment variables.

But the main point is that the shell handles all pairs listed prior to the command, automatically.