View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000551 | LDMud | Other | public | 2008-07-09 06:49 | 2021-04-08 22:56 |
| Reporter | fufu | Assigned To | fufu | ||
| Priority | low | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0000551: remove generated files from SVN | ||||
| Description | Some files are modified when building ldmud but not really interesting, and get in the way when committing changes to the repository. - doc/man/ldmud.1 (generated from src/ldmud-man.txt by make docs) - src/version.sh (modified by src/mk-patchlevel.sh) This is done intentionally, mk-patchlevel.sh says: # This way version.sh will always represent the latest revision number/date. But I disagree that this is advantageous. - src/configure We should provide an autogen.sh script or something similar instead. This would mean that before making releases, that script has to be run. | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
Yes, version.sh and configure annoyed me more than once while preparing a patch. Especially autogen.sh is commonly used among projects using autotools. And it prevents problems like Zortek had in 0000549. The necessary call of autogen.sh for SVN checkouts should be noted in INSTALL oder README though. |
|
|
I decided to just add autoconf autoconf/configure.in > configure to the top of my src/settings/sparse file. Raising the potential question, is there any harm in making it standard practice to generate it in motion instead of frontloading the effort in the repository (even for releases)? Is there an assumption that release users don't have autotools? |
|
|
There are quite a bunch of autotool versions in use and sometimes some versions are not able to process a configure.in correctly. I think, it is reasonable to ship a working configure in releases. It is anyway common practice to just use configure with bothering with additional tools. User who live on the bleeding edge of SVN can be expected to have a (suitable) autoconf available. |
|
|
I agree the autoconf files should be removed from trunk and generated for the releases using an autogen.sh. I don't care for version.sh (the release version has to be edited manually nevertheless, we only lose build date and svn revision). ldmud.1 should at least also be included in the release (I don't think it's that widespread), but can also be removed from trunk. |
|
|
I think, we will need the help of Lars here, because the release scripts have to be changed to call the script (autogen.sh?) we then use to generate the removed files. BTW: machine.h.in is auto-generated from configure.in bei autoheader/autoreconf as well. Do we have other candidates except configure, machine.h.in, doc/man/ldmud.1, src/version.sh? |
|
|
Related: I added a skeleton script autogen.sh which simply executes autoreconf and moved configure and machine.h.in into src/. Feed free to extend it. |
|
|
I think this is much better these days. - released autoconf files are in autoconf/ rather than src/, so they don't get committed by accident - version.sh is only updated when a release is made, not when running the autoconf/configure pipeline |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-07-09 06:49 | fufu | New Issue | |
| 2008-07-09 09:07 | zesstra | Note Added: 0000704 | |
| 2008-07-09 12:26 | zortek | Note Added: 0000707 | |
| 2008-07-09 12:44 | zesstra | Note Added: 0000709 | |
| 2008-07-10 08:43 | Gnomi | Note Added: 0000720 | |
| 2008-07-16 15:25 | zesstra | Note Added: 0000733 | |
| 2009-01-04 13:55 | zesstra | Note Added: 0000849 | |
| 2009-03-04 16:39 | zesstra | Status | new => confirmed |
| 2021-04-08 22:54 | fufu | Note Added: 0002579 | |
| 2021-04-08 22:56 | fufu | Assigned To | => fufu |
| 2021-04-08 22:56 | fufu | Status | confirmed => closed |
| 2021-04-08 22:56 | fufu | Resolution | open => fixed |
