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. ------------------------------------------------------------------------------ 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
