Conditional inclusion of AC_CONFIG_SUBDIRS
Based on the discussion between some of us on Tuesday, I tried to google for the lack of support for conditional inclusion of AC_CONFIG_SUBDIRS (e.g., if foo; then AC_CONFIG_SUBDIRS(foo); fi). However, everything I found so far seems to indicate that such conditional inclusion is allowed. Did I misunderstand the discussion, or is it something that has been recently fixed by autoconf? If this does work, should we just use the top-level configure to control the lower-level configures? -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
There's one other issue, even if it is conditional - it doesn't happen until the AC_OUTPUT step (this is so that rerunning config.status will rerun the subdir configures). So if the conditional support is fixed, then we'd have to ensure that we didn't need the results from any of those configures except as a side effect from AC_OUTPUT. But I don't think that is currently the case. Bill On Jan 25, 2008, at 12:11 PM, Pavan Balaji wrote:
Based on the discussion between some of us on Tuesday, I tried to google for the lack of support for conditional inclusion of AC_CONFIG_SUBDIRS (e.g., if foo; then AC_CONFIG_SUBDIRS(foo); fi). However, everything I found so far seems to indicate that such conditional inclusion is allowed. Did I misunderstand the discussion, or is it something that has been recently fixed by autoconf?
If this does work, should we just use the top-level configure to control the lower-level configures?
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
Bill, As far as I know, the CFLAGS are passed down to the sub-configures (I'll verify it again). We should, of course, make sure that we either don't need any other variable to get passed down, or figure out a way of passing through other variables as well. Assuming the above is true, do you see any other issues? As far as possible, I want to use the facilities provided by autoconf (while keeping in mind the random stuff it does occasionally). That'll make the build system a little easier to maintain, IMO. -- Pavan On 01/25/2008 12:26 PM, William Gropp wrote:
There's one other issue, even if it is conditional - it doesn't happen until the AC_OUTPUT step (this is so that rerunning config.status will rerun the subdir configures). So if the conditional support is fixed, then we'd have to ensure that we didn't need the results from any of those configures except as a side effect from AC_OUTPUT. But I don't think that is currently the case.
Bill
On Jan 25, 2008, at 12:11 PM, Pavan Balaji wrote:
Based on the discussion between some of us on Tuesday, I tried to google for the lack of support for conditional inclusion of AC_CONFIG_SUBDIRS (e.g., if foo; then AC_CONFIG_SUBDIRS(foo); fi). However, everything I found so far seems to indicate that such conditional inclusion is allowed. Did I misunderstand the discussion, or is it something that has been recently fixed by autoconf?
If this does work, should we just use the top-level configure to control the lower-level configures?
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
Note that the top level configure currently invokes subdir configures and, once they return, reads the "localdefs" file in the subdir. That won't work if AC_CONFIG_SUBDIRS is used. I completely agree on using the regular facilities as much as possible - where they don't work, I believe it will be better to add an extra level of indirection rather than try to force configure to behave in a different way. Bill On Jan 25, 2008, at 12:48 PM, Pavan Balaji wrote:
Bill,
As far as I know, the CFLAGS are passed down to the sub-configures (I'll verify it again). We should, of course, make sure that we either don't need any other variable to get passed down, or figure out a way of passing through other variables as well.
Assuming the above is true, do you see any other issues? As far as possible, I want to use the facilities provided by autoconf (while keeping in mind the random stuff it does occasionally). That'll make the build system a little easier to maintain, IMO.
-- Pavan
On 01/25/2008 12:26 PM, William Gropp wrote:
There's one other issue, even if it is conditional - it doesn't happen until the AC_OUTPUT step (this is so that rerunning config.status will rerun the subdir configures). So if the conditional support is fixed, then we'd have to ensure that we didn't need the results from any of those configures except as a side effect from AC_OUTPUT. But I don't think that is currently the case. Bill On Jan 25, 2008, at 12:11 PM, Pavan Balaji wrote:
Based on the discussion between some of us on Tuesday, I tried to google for the lack of support for conditional inclusion of AC_CONFIG_SUBDIRS (e.g., if foo; then AC_CONFIG_SUBDIRS(foo); fi). However, everything I found so far seems to indicate that such conditional inclusion is allowed. Did I misunderstand the discussion, or is it something that has been recently fixed by autoconf?
If this does work, should we just use the top-level configure to control the lower-level configures?
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
On Fri, 25 Jan 2008, Pavan Balaji wrote:
As far as I know, the CFLAGS are passed down to the sub-configures (I'll verify it again). We should, of course, make sure that we either don't need any other variable to get passed down, or figure out a way of passing through other variables as well.
Any exported environment variables will be read by subpackages defined in AC_CONFIG_SUBDIRS, that includes CFLAGS ... and user-specified env variables on the configure command.
Assuming the above is true, do you see any other issues? As far as possible, I want to use the facilities provided by autoconf (while keeping in mind the random stuff it does occasionally). That'll make the build system a little easier to maintain, IMO.
MPE makes extensive use of AC_CONFIG_SUBDIRS and it is working well but MPE consists of mostly "loosely coupled" subpackages. For "tighly coupled" subpackages like those in MPICH2, AC_CONFIG_SUBDIRS may not work as desired because of AC_OUTPUT step mentioned by Bill. (BTW, AC_OUTPUT is deprecated in autoconf-2.61 and is being replaced by AC_CONFIG_COMMANDS and friends) It will be great if MPICH2 uses AC_CONFIG_SUBDIRS, because that means "configure --help=recursive" will work but it probably involves quite a bit of work (if it is at all possible) to get MPICH2 to fit into autoconf's "loosely coupled" model. A.Chan
-- Pavan
On 01/25/2008 12:26 PM, William Gropp wrote:
There's one other issue, even if it is conditional - it doesn't happen until the AC_OUTPUT step (this is so that rerunning config.status will rerun the subdir configures). So if the conditional support is fixed, then we'd have to ensure that we didn't need the results from any of those configures except as a side effect from AC_OUTPUT. But I don't think that is currently the case.
Bill
On Jan 25, 2008, at 12:11 PM, Pavan Balaji wrote:
Based on the discussion between some of us on Tuesday, I tried to google for the lack of support for conditional inclusion of AC_CONFIG_SUBDIRS (e.g., if foo; then AC_CONFIG_SUBDIRS(foo); fi). However, everything I found so far seems to indicate that such conditional inclusion is allowed. Did I misunderstand the discussion, or is it something that has been recently fixed by autoconf?
If this does work, should we just use the top-level configure to control the lower-level configures?
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
Bill, I was talking to the PVFS folks about this and they mentioned a similar problem they were facing. They solve it at "make" time rather than at configure time. Each sub-configure generates files called modules.mk in each required sub-directory (similar to the localdefs files we have). At configure time, these modules.mk files are blindly included into the top-level Makefile (irrespective of what they contain). The advantage of this model is that we can use the AC_CONFIG_SUBDIRS to include sub-directories, which will allow us to use all the recursive help commands and passing of environment variables appropriately. Since you are a lot more familiar with the MPICH2 build system, do you see any issues with this model? -- Pavan On 01/25/2008 02:15 PM, Anthony Chan wrote:
On Fri, 25 Jan 2008, Pavan Balaji wrote:
As far as I know, the CFLAGS are passed down to the sub-configures (I'll verify it again). We should, of course, make sure that we either don't need any other variable to get passed down, or figure out a way of passing through other variables as well.
Any exported environment variables will be read by subpackages defined in AC_CONFIG_SUBDIRS, that includes CFLAGS ... and user-specified env variables on the configure command.
Assuming the above is true, do you see any other issues? As far as possible, I want to use the facilities provided by autoconf (while keeping in mind the random stuff it does occasionally). That'll make the build system a little easier to maintain, IMO.
MPE makes extensive use of AC_CONFIG_SUBDIRS and it is working well but MPE consists of mostly "loosely coupled" subpackages. For "tighly coupled" subpackages like those in MPICH2, AC_CONFIG_SUBDIRS may not work as desired because of AC_OUTPUT step mentioned by Bill. (BTW, AC_OUTPUT is deprecated in autoconf-2.61 and is being replaced by AC_CONFIG_COMMANDS and friends)
It will be great if MPICH2 uses AC_CONFIG_SUBDIRS, because that means "configure --help=recursive" will work but it probably involves quite a bit of work (if it is at all possible) to get MPICH2 to fit into autoconf's "loosely coupled" model.
A.Chan
-- Pavan
On 01/25/2008 12:26 PM, William Gropp wrote:
There's one other issue, even if it is conditional - it doesn't happen until the AC_OUTPUT step (this is so that rerunning config.status will rerun the subdir configures). So if the conditional support is fixed, then we'd have to ensure that we didn't need the results from any of those configures except as a side effect from AC_OUTPUT. But I don't think that is currently the case.
Bill
On Jan 25, 2008, at 12:11 PM, Pavan Balaji wrote:
Based on the discussion between some of us on Tuesday, I tried to google for the lack of support for conditional inclusion of AC_CONFIG_SUBDIRS (e.g., if foo; then AC_CONFIG_SUBDIRS(foo); fi). However, everything I found so far seems to indicate that such conditional inclusion is allowed. Did I misunderstand the discussion, or is it something that has been recently fixed by autoconf?
If this does work, should we just use the top-level configure to control the lower-level configures?
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
FYI:
From the book "Managing Projects with make" by Andrew Oram and Steve Talbott, O'Reilly. (9/96 print)
Page 88 states that inlcude statement is not available in all variants. Also, on page 129 (Appendix C) include statement: Supported on System V, but not BSD 4.3 Don't know for sure the statment is still true for modern make. A.Chan On Sun, 27 Jan 2008, Pavan Balaji wrote:
Bill,
I was talking to the PVFS folks about this and they mentioned a similar problem they were facing. They solve it at "make" time rather than at configure time. Each sub-configure generates files called modules.mk in each required sub-directory (similar to the localdefs files we have). At configure time, these modules.mk files are blindly included into the top-level Makefile (irrespective of what they contain).
The advantage of this model is that we can use the AC_CONFIG_SUBDIRS to include sub-directories, which will allow us to use all the recursive help commands and passing of environment variables appropriately.
Since you are a lot more familiar with the MPICH2 build system, do you see any issues with this model?
-- Pavan
On 01/25/2008 02:15 PM, Anthony Chan wrote:
On Fri, 25 Jan 2008, Pavan Balaji wrote:
As far as I know, the CFLAGS are passed down to the sub-configures (I'll verify it again). We should, of course, make sure that we either don't need any other variable to get passed down, or figure out a way of passing through other variables as well.
Any exported environment variables will be read by subpackages defined in AC_CONFIG_SUBDIRS, that includes CFLAGS ... and user-specified env variables on the configure command.
Assuming the above is true, do you see any other issues? As far as possible, I want to use the facilities provided by autoconf (while keeping in mind the random stuff it does occasionally). That'll make the build system a little easier to maintain, IMO.
MPE makes extensive use of AC_CONFIG_SUBDIRS and it is working well but MPE consists of mostly "loosely coupled" subpackages. For "tighly coupled" subpackages like those in MPICH2, AC_CONFIG_SUBDIRS may not work as desired because of AC_OUTPUT step mentioned by Bill. (BTW, AC_OUTPUT is deprecated in autoconf-2.61 and is being replaced by AC_CONFIG_COMMANDS and friends)
It will be great if MPICH2 uses AC_CONFIG_SUBDIRS, because that means "configure --help=recursive" will work but it probably involves quite a bit of work (if it is at all possible) to get MPICH2 to fit into autoconf's "loosely coupled" model.
A.Chan
-- Pavan
On 01/25/2008 12:26 PM, William Gropp wrote:
There's one other issue, even if it is conditional - it doesn't happen until the AC_OUTPUT step (this is so that rerunning config.status will rerun the subdir configures). So if the conditional support is fixed, then we'd have to ensure that we didn't need the results from any of those configures except as a side effect from AC_OUTPUT. But I don't think that is currently the case.
Bill
On Jan 25, 2008, at 12:11 PM, Pavan Balaji wrote:
Based on the discussion between some of us on Tuesday, I tried to google for the lack of support for conditional inclusion of AC_CONFIG_SUBDIRS (e.g., if foo; then AC_CONFIG_SUBDIRS(foo); fi). However, everything I found so far seems to indicate that such conditional inclusion is allowed. Did I misunderstand the discussion, or is it something that has been recently fixed by autoconf?
If this does work, should we just use the top-level configure to control the lower-level configures?
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
Anthony is correct - include was not in the original make and it isn't universal. One branch of BSD development used the C preprocessor, causing lines like #include (a make comment) to include a file. However, I believe most current makes do accept include. Someone should check AIX, Solaris, and HP, as these are likely to be the most different from the GNU make. The PVFS folks can take advantage of many gcc and GNU make features; that's absolutely right for their environment but you need to be careful about portability. Also note that some of the information in the localdefs is used within the configure, not simply as additional data for the Makefile. It would be good to clearly distinguish configure time (both in scope and at AC_OUTPUT) and make-time operations. Bill On Jan 27, 2008, at 10:29 PM, Pavan Balaji wrote:
Bill,
I was talking to the PVFS folks about this and they mentioned a similar problem they were facing. They solve it at "make" time rather than at configure time. Each sub-configure generates files called modules.mk in each required sub-directory (similar to the localdefs files we have). At configure time, these modules.mk files are blindly included into the top-level Makefile (irrespective of what they contain).
The advantage of this model is that we can use the AC_CONFIG_SUBDIRS to include sub-directories, which will allow us to use all the recursive help commands and passing of environment variables appropriately.
Since you are a lot more familiar with the MPICH2 build system, do you see any issues with this model?
-- Pavan
On 01/25/2008 02:15 PM, Anthony Chan wrote:
On Fri, 25 Jan 2008, Pavan Balaji wrote:
As far as I know, the CFLAGS are passed down to the sub- configures (I'll verify it again). We should, of course, make sure that we either don't need any other variable to get passed down, or figure out a way of passing through other variables as well. Any exported environment variables will be read by subpackages defined in AC_CONFIG_SUBDIRS, that includes CFLAGS ... and user-specified env variables on the configure command. Assuming the above is true, do you see any other issues? As far as possible, I want to use the facilities provided by autoconf (while keeping in mind the random stuff it does occasionally). That'll make the build system a little easier to maintain, IMO. MPE makes extensive use of AC_CONFIG_SUBDIRS and it is working well but MPE consists of mostly "loosely coupled" subpackages. For "tighly coupled" subpackages like those in MPICH2, AC_CONFIG_SUBDIRS may not work as desired because of AC_OUTPUT step mentioned by Bill. (BTW, AC_OUTPUT is deprecated in autoconf-2.61 and is being replaced by AC_CONFIG_COMMANDS and friends) It will be great if MPICH2 uses AC_CONFIG_SUBDIRS, because that means "configure --help=recursive" will work but it probably involves quite a bit of work (if it is at all possible) to get MPICH2 to fit into autoconf's "loosely coupled" model. A.Chan
-- Pavan
On 01/25/2008 12:26 PM, William Gropp wrote:
There's one other issue, even if it is conditional - it doesn't happen until the AC_OUTPUT step (this is so that rerunning config.status will rerun the subdir configures). So if the conditional support is fixed, then we'd have to ensure that we didn't need the results from any of those configures except as a side effect from AC_OUTPUT. But I don't think that is currently the case.
Bill
On Jan 25, 2008, at 12:11 PM, Pavan Balaji wrote:
Based on the discussion between some of us on Tuesday, I tried to google for the lack of support for conditional inclusion of AC_CONFIG_SUBDIRS (e.g., if foo; then AC_CONFIG_SUBDIRS(foo); fi). However, everything I found so far seems to indicate that such conditional inclusion is allowed. Did I misunderstand the discussion, or is it something that has been recently fixed by autoconf?
If this does work, should we just use the top-level configure to control the lower-level configures?
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
Also note that some of the information in the localdefs is used within the configure, not simply as additional data for the Makefile. It would
Ah, I missed that part. Time for me to do some more digging into the build system before I look for solutions. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji
participants (3)
-
Anthony Chan -
Pavan Balaji -
William Gropp