Re: [HACKERS] Re: Configure problem, redux (was Re: TCL installation troubles)
От | Brook Milligan |
---|---|
Тема | Re: [HACKERS] Re: Configure problem, redux (was Re: TCL installation troubles) |
Дата | |
Msg-id | 199810272127.OAA00486@trillium.nmsu.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Configure problem, redux (was Re: TCL installation troubles) (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] Re: Configure problem, redux (was Re: TCL installation troubles)
(Bruce Momjian <maillist@candle.pha.pa.us>)
|
Список | pgsql-hackers |
The problem here is that you are duplicating the normal configure processing in every Makefile that needs it. This willget old very fast, and hard to maintain. configure does this already, and automatically, in one place. Yes, you mustre-run configure, and you do loose your changes, but pulling all the stuff into every Makefile seems worse. We are only doing this for the *.sql files because they don't have within them some ability to do argument expansion. This is definitely not good for all the Makefiles or source code, both of which can get what they need in a single place (Makefile.global or config.h). I am not advocating changing that. In fact, I am agreeing with the idea of becoming more centralized for those parts of the code that can handle it, i.e., Makefiles and C source. For *.sql files there are two choices: - have configure do the expansion. This requires either special variables or expansion of lots of variables, neither ofwhich is a good solution because they require unusual coding practices or prevent easy maintenance (i.e., change of Makefile.global)later. - have make do the expansion. Certainly this puts some of configure's job into some Makefiles, but it offers the advantagethat Makefile.global can be changed and those changes will propagate where they are needed. It seems like we need a well-documented policy decision, perhaps between the two following options (plus any others people want to formulate). 1. we are only speaking (to my knowledge) of the library locations, so use ${expanded_libdir} in *.sql files; configurewill do the right thing with these (i.e., only expand this but leave the "normal" variables unexpanded so thatchanges to Makefile.global propagate easily), but changes to Makefile.global cannot touch the configured choice for${expanded_libdir}. Changes to that require going through all the *.sql files seeking those with the wrong expansions(or reconfiguring). 2. add rules to those few Makefiles that require it so that make will expand for *.sql based on the configured choices. Changes to Makefile.global will do the right thing. The latter perhaps duplicates a tiny bit of configure, but is more flexible. If the rule is made generic (which it really is) it can even be put into Makefile.global as a pattern target and not even worried about in any of the Makefiles; if there is a *.sql.in it will be made into *.sql with the correct substitution, end of story, no need to be concerned with duplicating parts of configure all over the place. This follows the recent trend for a centralized set of rules for shared library handling. Why not a central place for the common *.sql substitution as well, so that what is in Makefile.global gets propagated? Cheers, Brook
В списке pgsql-hackers по дате отправления:
Следующее
От: Bruce MomjianДата:
Сообщение: Re: [HACKERS] Re: Configure problem, redux (was Re: TCL installation troubles)