config/configure.py -> configure?
On Jul 17, 2008, at 1:09 PM, Satish Balay wrote: > > And the reason we want to promote usage of ./config/bgp-ibm-opt.py > notation is so that we we don't have users creating shell scripts with > configure options in them. What is the proceedure that people use when configureing for packages based on autoconf. Do they "create shell scripts with configure options in them"? Do they always just magically type them at the command prompt properly? Do they never use more than 1 or 2 options? If we could support the same way that this is done with autoconf packages that would improve a users experience with PETSc. > > > Satish > > >> From: Barry Smith >> >>petsc-dev folks, >> >>is there any technical reason we cannot just change the name of >> config/configure.py to configure? >> (does Windows care about the .py and python in cygwin?) >> >>is there any nontechnical reason we cannot/should not make the >> change? >> >>Barry >> >> My thinking is "the more like what people are use to, the less other >> people have to learn/deal with, >> the easier it is for people". Seems like a "little thing" but little >> things accumulate into big things if you >> don't eliminate as many little things as possible. >> >> >
config/configure.py -> configure?
On Thu, 17 Jul 2008, Barry Smith wrote: > > On Jul 17, 2008, at 1:09 PM, Satish Balay wrote: > > > > > And the reason we want to promote usage of ./config/bgp-ibm-opt.py > > notation is so that we we don't have users creating shell scripts with > > configure options in them. > > What is the proceedure that people use when configureing for packages > based on autoconf. Do they "create shell scripts with configure options in > them"? > Do they always just magically type them at the command prompt properly? > Do they never use more than 1 or 2 options? I guess - once the list of options become sufficiently large - some script gets used.. With PETSc - invariably the configure options list is long. > If we could support the same way that this is done with autoconf packages > that would improve a users experience with PETSc. I guess we don't prevent the usage from shell scripts. We just promote the alternative usage of adding configure options in a python script. Satish
config/configure.py -> configure?
On Thu, 17 Jul 2008, Satish Balay wrote: > > If we could support the same way that this is done with autoconf packages > > that would improve a users experience with PETSc. > > I guess we don't prevent the usage from shell scripts. We just promote > the alternative usage of adding configure options in a python script. And we generate $PETSC_ARCH/config/configure.py - which can be rerun by the user. Alternative would be to generate this file in a shell-script notation.. Satish
config/configure.py -> configure?
Speaking of configure and user experiences, I just noticed that PETSc defines top_builddir (in petscconf), which conflicts with automake-generated makefiles, making it impossible in some cases to include PETSc's petsconf file into Makefile.am (as far as I know that's the only thing that causes problems). I hate automake in general, but sometimes you are stuck with it and it's very nice to be able to include PETSc make snippets even in automake files and avoid a lot of pain. Anyway, since this is in a file that gets copied to the install location, I think in general it would be best to avoid defining build tree-related variables (especially those that conflict with auto-generated ones from other tools). Thoughts? Boyana Satish Balay wrote: > On Thu, 17 Jul 2008, Satish Balay wrote: > > >>> If we could support the same way that this is done with autoconf packages >>> that would improve a users experience with PETSc. >>> >> I guess we don't prevent the usage from shell scripts. We just promote >> the alternative usage of adding configure options in a python script. >> > > And we generate $PETSC_ARCH/config/configure.py - which can be rerun > by the user. Alternative would be to generate this file in a > shell-script notation.. > > Satish > > -- Boyana Norris, Computer Scientist| Email: norris at mcs.anl.gov Argonne National Laboratory | Phone: +1 (630) 252 7908 http://www.mcs.anl.gov/~norris/ | Fax: +1 (630) 252 5986
config/configure.py -> configure?
On Jul 17, 2008, at 3:58 PM, Boyana Norris wrote: > Speaking of configure and user experiences, I just noticed that > PETSc defines top_builddir (in petscconf), which conflicts with > automake-generated makefiles, making it impossible in some cases to > include PETSc's petsconf file into Makefile.am (as far as I know > that's the only thing that causes problems). I hate automake in > general, but sometimes you are stuck with it and it's very nice to > be able to include PETSc make snippets even in automake files and > avoid a lot of pain. > > Anyway, since this is in a file that gets copied to the install > location, I think in general it would be best to avoid defining > build tree-related variables (especially those that conflict with > auto-generated ones from other tools). Thoughts? > I think this was originally in there when Matt was mucking around with libtool (the gnu one, not the Mac one). I don't think it is used and should be removed. Once Matt confirms this, we will rip it out. Barry > Boyana > > Satish Balay wrote: >> On Thu, 17 Jul 2008, Satish Balay wrote: >> >> If we could support the same way that this is done with autoconf packages that would improve a users experience with PETSc. >>> I guess we don't prevent the usage from shell scripts. We just >>> promote >>> the alternative usage of adding configure options in a python >>> script. >>> >> >> And we generate $PETSC_ARCH/config/configure.py - which can be rerun >> by the user. Alternative would be to generate this file in a >> shell-script notation.. >> >> Satish >> >> > > -- > Boyana Norris, Computer Scientist| Email: norris at mcs.anl.gov > Argonne National Laboratory | Phone: +1 (630) 252 7908 > http://www.mcs.anl.gov/~norris/ > | Fax: +1 (630) 252 5986 >
config/configure.py -> configure?
On Thu, Jul 17, 2008 at 4:14 PM, Barry Smith wrote: > > On Jul 17, 2008, at 3:58 PM, Boyana Norris wrote: > >> Speaking of configure and user experiences, I just noticed that PETSc >> defines top_builddir (in petscconf), which conflicts with automake-generated >> makefiles, making it impossible in some cases to include PETSc's petsconf >> file into Makefile.am (as far as I know that's the only thing that causes >> problems). I hate automake in general, but sometimes you are stuck with it >> and it's very nice to be able to include PETSc make snippets even in >> automake files and avoid a lot of pain. >> >> Anyway, since this is in a file that gets copied to the install location, >> I think in general it would be best to avoid defining build tree-related >> variables (especially those that conflict with auto-generated ones from >> other tools). Thoughts? >> > > I think this was originally in there when Matt was mucking around with > libtool (the gnu one, not the Mac one). > I don't think it is used and should be removed. Once Matt confirms this, we > will rip it out. Yep, its a relic. Rip it out. Matt > Barry > >> Boyana >> >> Satish Balay wrote: >>> >>> On Thu, 17 Jul 2008, Satish Balay wrote: >>> >>> > If we could support the same way that this is done with autoconf > packages > that would improve a users experience with PETSc. > I guess we don't prevent the usage from shell scripts. We just promote the alternative usage of adding configure options in a python script. >>> >>> And we generate $PETSC_ARCH/config/configure.py - which can be rerun >>> by the user. Alternative would be to generate this file in a >>> shell-script notation.. >>> >>> Satish >>> >>> >> >> -- >> Boyana Norris, Computer Scientist| Email: norris at mcs.anl.gov >> Argonne National Laboratory | Phone: +1 (630) 252 7908 >> http://www.mcs.anl.gov/~norris/ | Fax: +1 (630) 252 5986 >> > > -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
config/configure.py -> configure?
The primary reason we have ./config/configure.py [instead of ./configure] is due to the presence of ./config/bgp-ibm-opt.py etc scripts which use ./config/configure.py So now usage of ./config/configure.py or ./config/bgp-ibm-opt.py is consistant. We can have ./configure as a link to ./config/configure.py [at the cost of making the user interface of ./configure vs ./config/bgp-ibm-opt.py inconsistant] And the reason we want to promote usage of ./config/bgp-ibm-opt.py notation is so that we we don't have users creating shell scripts with configure options in them. Satish > From: Barry Smith > > petsc-dev folks, > > is there any technical reason we cannot just change the name of > config/configure.py to configure? > (does Windows care about the .py and python in cygwin?) > > is there any nontechnical reason we cannot/should not make the > change? > > Barry > > My thinking is "the more like what people are use to, the less other > people have to learn/deal with, > the easier it is for people". Seems like a "little thing" but little > things accumulate into big things if you > don't eliminate as many little things as possible. > >
