Just a thought, generally I’m very much against generated files being part of the git repository.
It just adds junk to diffs and repository status when developing locally.
I would think we can remove configure… looking at other community discussions…most seem to agree to not include any file that is not hand-edited.
However, there are some time tested projects like postgres that do include the generated configure in the repository.
Would you like to create a defect in the pbspro issue tracker: https://pbspro.atlassian.net/projects/PP/issues to get this addressed?
Ok, it’s there as PP-292.
1 Like
The build and test systems used during initial OSS development did not have the required tools (autoconf, automake, etc.) installed, which is why the autogenerated files were checked into the repo. I don’t have a problem removing them, at least for Linux systems. However, the world is more than Linux. Removing them may be problematic if someone wanted to build PBS Pro for Solaris or AIX. I’m also curious to see what happens when Microsoft rolls out bash for Windows this summer. For the time being, I would like to leave the files in the repo unless there is a strong technical argument to remove them.
One clean solution would be to remove them from the repo, but re-generate them for releases.
As a side note, I would be all for a more portable replacement for autotools.
I see that you have raised the Jira ticket for the work here: https://pbspro.atlassian.net/browse/PP-292. Kindly feel free to work on it and submit a pull request.
Going forward, we would love to hear about your suggestion to replace autotools. Are you hinting at something like maven, or cmake? Autotools is not very new, but we chose it seems to be well supported and used by large projects, especially ones based on C/Unix.
Could you please elaborate on what you mean by “a more portable replacement for autotools”?
CMake is a solid choice, but there is also a possibility for something new like Bazel.
And as far as portability goes, autotools is portable as C/C++ is portable. It supports everything, but you write everything yourself. For example you can’t get a Visual Studio project out of autotools (unless, you write manual code to do that).
1 Like
CMake is one of the options we considered, and a good one at that. After examining several OSS projects we found that GNU autotools seemed to be the most commonly used. Rather than transition to a different tool, we decided to update what was already there. I’ll take your suggestion as a vote for CMake. If we get more CMake votes, we can definitely reconsider transitioning.