We have discussed how we want to maintain some of the automake files in the source tree after a package is converted to cmake. Those files provide us an historical record of what was.
I notice the subdirs text file no longer is included. That file played a role with using the DO_NOT_COMPILE environment variable, which is helpful with troubleshooting. The DO_NOT_COMPILE options are replaced in cmake with -DWITH options, but the subdirs text file lets us know the cmake conversion is good.
Could we get those subdirs files restored to the sources?
Darrell
Darrell Anderson wrote:
We have discussed how we want to maintain some of the automake files in the source tree after a package is converted to cmake. Those files provide us an historical record of what was.
I would expect that historical data is available through the revision system (Git) at least? Cluttering the source packages with unused files doesn't really seem like the best idea to me.
Best regards, Julius
We have discussed how we want to maintain some of the
automake files in the source tree after a package is converted to cmake. Those files provide us an historical record of what was.
I would expect that historical data is available through the revision system (Git) at least? Cluttering the source packages with unused files doesn't really seem like the best idea to me.
Where is the clutter? Every automake package still has that file.
They are small text files with important information, requiring less storage space than other automake files retained in the directory. :)
I don't find those files on my local GIT repository for the cmake converted packages. The current cmake conversions took place before the SVN to GIT migration and I suspect those files are not part of GIT.
Darrell
Darrell Anderson wrote:
We have discussed how we want to maintain some of the
automake files in the source tree after a package is converted to cmake. Those files provide us an historical record of what was.
I would expect that historical data is available through the revision system (Git) at least? Cluttering the source packages with unused files doesn't really seem like the best idea to me.
Where is the clutter? Every automake package still has that file.
They are small text files with important information, requiring less storage space than other automake files retained in the directory. :)
I don't find those files on my local GIT repository for the cmake converted packages. The current cmake conversions took place before the SVN to GIT migration and I suspect those files are not part of GIT.
When the conversion from Subversion to GIT took place, all the previous revisions should have been imported as well.
You will not find the files if you just check out the repository, but when you use the git command to go back to an older revision, you will be able to get access to these files again. Normally this should also be possible through the web interface.
Another option is using the original Subversion repository to go back in time to get these files.
The point of clutter is not so much regarding disk space as it is to having extra files that are maybe completely unused. At some point in the future it could be confusing what files are still necessary for building and which ones just contain information. Because everything is still available through the revision system anyhow, it should not be necessary to keep these files in the source package. In addition the revision system will give you information about all the changes made to these files in the past, so you can get even more info in that way.
Julius
On Wednesday 25 January 2012 12:58:22 pm Julius Schwartzenberg wrote:
[putolin]
The point of clutter is not so much regarding disk space as it is to having extra files that are maybe completely unused. At some point in the future it could be confusing what files are still necessary for building and which ones just contain information. Because everything is still available through the revision system anyhow, it should not be necessary to keep these files in the source package. In addition the revision system will give you information about all the changes made to these files in the past, so you can get even more info in that way.
Julius
They are not very big and can aid in packaging.
I would rather see them deleted _AFTER_ the cmake conversions are completed and the packages build and work on most distributions.
Baho Utot wrote:
On Wednesday 25 January 2012 12:58:22 pm Julius Schwartzenberg wrote:
[putolin]
The point of clutter is not so much regarding disk space as it is to having extra files that are maybe completely unused. At some point in the future it could be confusing what files are still necessary for building and which ones just contain information. Because everything is still available through the revision system anyhow, it should not be necessary to keep these files in the source package. In addition the revision system will give you information about all the changes made to these files in the past, so you can get even more info in that way.
Julius
They are not very big and can aid in packaging.
I would rather see them deleted _AFTER_ the cmake conversions are completed and the packages build and work on most distributions.
Of course, as long as they are still used, they need to stay. But for historical records, there are the old Git revisions.
They are not very big and can aid in packaging.
I would rather see them deleted _AFTER_ the cmake
conversions are completed
and the packages build and work on most distributions.
Of course, as long as they are still used, they need to stay. But for historical records, there are the old Git revisions.
Those subdirs text files correspond directly to the old DO_NOT_COMPILE environment variable option for building any KDE3/Trinity package. The equivalent in cmake is the -DWITH build option.
Those subdirs files help us examine any cmake converted package to ensure all elements were converted and there is a corresponding -DWITH option. Sometimes in those conversions an option gets missed. That is normal and to be expected. Those subdirs text files provide us a way to double-check ourselves.
Someday, yes, those files could be deleted, but we should preserve them for several releases until we all are sure that everything builds correctly on many distros. For now we should not have to hunt through previous GIT/SVN versions to read those files.
Darrell
-
Baho Utot -
Calvin Morrison -
Darrell Anderson -
Julius Schwartzenberg