On 6 May 2015 at 17:48, NightStrike <[email protected]> wrote: > On Wed, May 6, 2015 at 10:39 AM, Alon Bar-Lev <[email protected]> wrote: >> On 6 May 2015 at 17:34, NightStrike <[email protected]> wrote: >>> On Wed, May 6, 2015 at 10:08 AM, Alon Bar-Lev <[email protected]> wrote: >>>>> On Wed, May 6, 2015 at 6:25 AM, Alon Bar-Lev <[email protected]> >>>>> wrote: >>>>> > this effects only top level package, if crt is to be built: >>>>> > 1. install headers into builddir for staging >>>>> > 2. adjust CPPFLAGS for tools and libraries to find local headers >>>>> >>>>> This is a very bad idea. You are never allowed to modify the CPPFLAGS >>>>> variable. That is a user only variable, not for use by the package. >>>> >>>> appending (not replacing) to CPPFLAGS or CFLAGS or LDFLAGS within >>>> autoconf is widely used, I never saw that comment. I can remove it in >>>> favour of yet another substitution. I do not see the benefit, nor do I >>>> see such restriction in the autoconf manual. >>>> >>>>> > 3. disable sysroot for crt so search path contain only local headers >>>>> >>>>> This makes no sense. Just change the sysroot that you are passing in. >>>> >>>> there is no need to do so, as the CPPFLAGS are enough and respected by >>>> the crt, the default of having sysroot as $prefix when sysroot is >>>> something that may be considered to change, default should probably be >>>> no. >>> >>> http://www.gnu.org/software/automake/manual/html_node/User-Variables.html#User-Variables >>> >>> "Sometimes package developers are tempted to set user variables such >>> as CFLAGS because it appears to make their job easier. However, the >>> package itself **should never set a user variable**, particularly not >>> to include switches that are required for proper compilation of the >>> package. Since these variables are documented as being for the package >>> builder, that person rightfully expects to be able to override any of >>> these variables at build time." >> >> this is correct for the automake part, you use AM_CPPFLAGS to or >> _CPPFLAGS to alter flags, but at autoconf level appending more flags >> is not something that far fetched, especially when the top level >> configure script is customizing the environment for the subpackages. > > Yes, it's from the automake manual, but the point is still the same. > It's a variable meant for the user, not the build system... which > brings me to my next point... > >> however, I have not understood what you suggest as alternative. as far >> as I understand, we have N subpackages that we to build, adding a -I<> >> to a directory in builddir only if top level package is used. > > I was writing separate emails to do that, but I'll just give the short > version here, which is that, simply, I think a lot of what you're > trying to do belongs in make, not configure. You can do this a lot > more safely using conditionals and make variables, as can be seen > elsewhere in many places across the build system. > > I will send you what I have as per your request when I am home > tomorrow, and maybe it'll serve as a more concrete example for > discussion.
That's will be great! The way I see this is that the top level package just automate the build of the subpackages, it just replacement of a script that execute each subpackage with appropriate settings. I perfectly agree to your note if I to modify one of the subpackages that actually build something, but in this case I do not see any reason to make the subpackages complex just for the sake of top level to be able to instrument thecomplete build sequence. Waiting for your hints. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
