Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

autotools fixes #95

Closed
wants to merge 6 commits into from
Closed

autotools fixes #95

wants to merge 6 commits into from

Conversation

umlaeute
Copy link
Contributor

@umlaeute umlaeute commented Dec 10, 2019

the autotools setup is in a sorry state, and seems to be not very well tested.

it wrongly uses CFLAGS (and CPPFLAGS) for C++-projects (ndvi, facebl0r, facedetect), resulting in

  • unability to build out-of-tree
  • not passing of crucial build-flags

afaict, there's also a misunderstanding of how AM_*FLAGS are supposed to work:
they are really used to define fallback-flags, if no per-target flags are specified. however, if you do specify per-target flags (as is the case for a couple of filters), the AM_*FLAGS will be ignored unless manually added.

it seems that autotools is a 2nd-class citizen (as opposed to cmake), and is not tested with CI.
it's probably OK to only support a single build-system, but then we should just drop the unsupported build-systems completely...

EDIT: sorry, I missed that autotools are indeed tested in .travis.yml; too well hidden behind docker :-)

AM_CFLAGS is really a fallback, if there are no explicit per-target CFLAGS set
CFLAGS is really only for C-files
CPPFLAGS is for the C-PreProcessor
it's redundant, as C(XX)FLAGS are always added to each target
@jaromil
Copy link
Member

jaromil commented Dec 10, 2019

Thanks! Its still true that the cmake setup is the best maintained and AFAIK most used.
Feedback is welcome on your proposition, perhaps to be debated also on the mailinglist?
I agree that maintaining one build system is probably enough.

@ddennedy
Copy link
Collaborator

I vote to remove the autotools build.

@umlaeute
Copy link
Contributor Author

even though i personally despise CMake and very much prefer autotools, i completely agree (as hinted in the original post) that it's better to remove autotools than to have it lingering around unmaintained.

@umlaeute
Copy link
Contributor Author

as of frei0r-1.8, autotools is still (or: again?) broken, as it references a non-existing file TODO.

@umlaeute
Copy link
Contributor Author

ah, i just noticed that there's ee21d09 right after v1.8.0, which fixes this.

it would be fantastic if the build-systems were tested before doing a release (probably using a CI; my casual glance seems to indicate that the travis-ci no longer runs autotools builds).

or: simple remove the buildsystem that is unmaintained.

@jaromil
Copy link
Member

jaromil commented Dec 27, 2022

Hi @umlaeute !! thanks for your maintenance and patience, I'm following up on your advice and consolidating the cmake based build, will setup a ci for test builds using both make, ninja and nmake for msvc target, see #130

@jaromil jaromil closed this Dec 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants