Skip to content

Fix Makefile#99

Open
bakatrouble wants to merge 1 commit intogrishka:publicfrom
bakatrouble:fix-makefile
Open

Fix Makefile#99
bakatrouble wants to merge 1 commit intogrishka:publicfrom
bakatrouble:fix-makefile

Conversation

@bakatrouble
Copy link
Copy Markdown
Contributor

Makefile templates are missing video/VideoPacketSender and video/VideoFEC includes

@zevlg
Copy link
Copy Markdown
Contributor

zevlg commented Oct 25, 2019

This PR fixes #96

Copy link
Copy Markdown

@andy-shev andy-shev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makefile.in mustn't be part of repository. (Means you should drop that change from the commit, and leave only the proper one, i.e. in Makefile.am)

@mymedia2
Copy link
Copy Markdown
Contributor

mymedia2 commented Jan 6, 2021

@andy-shev

Makefile.in mustn't be part of repository

That's not dogma. There are several approaches to Autotools with version control systems. See comparisons:

  1. https://www.gnu.org/software/automake/manual/automake.html#CVS
  2. https://www.gnu.org/software/gettext/manual/gettext.html#Files-under-Version-Control

@grishka
Copy link
Copy Markdown
Owner

grishka commented Jan 6, 2021

I've seen many repositories include configure. This way you don't need to run anything to generate it and don't need any build-time dependencies.

@andy-shev
Copy link
Copy Markdown

andy-shev commented Jan 7, 2021

I've seen many repositories include configure. This way you don't need to run anything to generate it and don't need any build-time dependencies.

If they are all wrong, why should be you? https://en.wikipedia.org/wiki/Cargo_cult_programming

And to my point: VCS and release tarball are different in this case. when you build your release with make dist (https://www.gnu.org/software/automake/manual/html_node/Preparing-Distributions.html) you will get everything needed. Simply learn your tools (as I already mentioned somewhere else in this repo) :-)

@grishka
Copy link
Copy Markdown
Owner

grishka commented Jan 7, 2021

The idea is that you clone the repo, run ./configure && make and that's it. Including configure is simply making it more convenient for your users by not requiring them to make sense of your build system. And making my project convenient for my users is my number one priority.

@andy-shev
Copy link
Copy Markdown

andy-shev commented Jan 7, 2021

The idea is that you clone the repo, run ./configure && make and that's it. Including configure is simply making it more convenient for your users by not requiring them to make sense of your build system. And making my project convenient for my users is my number one priority.

I have updates my comment above. For your convenience repeating here the additional part:

And to my point: VCS and release tarball are different in this case. when you build your release with make dist (https://www.gnu.org/software/automake/manual/html_node/Preparing-Distributions.html) you will get everything needed. Simply learn your tools (as I already mentioned somewhere else in this repo) :-)

To @mymedia2: See above as well. Feel free to ask additional questions if you have something to be cleared.

@mymedia2
Copy link
Copy Markdown
Contributor

mymedia2 commented Jan 7, 2021

@andy-shev but your link says nothing about version control systems. Why do not you admit a workflow with generated files in Git? It is discussed in Automake docs.

@andy-shev
Copy link
Copy Markdown

@andy-shev but your link says nothing about version control systems. Why do not you admit a workflow with generated files in Git? It is discussed in Automake docs.

It's suboptimal to have generated files under VCS. User will regenerate them anyway (you never know what the actual version of autotools on the user's side). I see only disadvantages of this. And on top of that the standard de facto is to produce releases. If you do tags in VCS it's user's responsibility to generate necessary files on their side.

@andy-shev
Copy link
Copy Markdown

Applying these changes as is is (semi-)wrong. Having the Makefile.in and other prebuilt stuff in the repository is suboptimal and confusing. Makes a little sense.

@Chintaro24
Copy link
Copy Markdown

Applying these changes as is is (semi-)wrong. Having the Makefile.in and other prebuilt stuff in the repository is suboptimal and confusing. Makes a little sense.

Please accept my apologies, experts, I am a beginner. I sincerely apologize and would be very grateful if you could correct me. 🙏🏻🙏🏻

@andy-shev
Copy link
Copy Markdown

Applying these changes as is is (semi-)wrong. Having the Makefile.in and other prebuilt stuff in the repository is suboptimal and confusing. Makes a little sense.

Please accept my apologies, experts, I am a beginner. I sincerely apologize and would be very grateful if you could correct me. 🙏🏻🙏🏻

It's not your fault per se. The problem I'm escalating is with uselessness of keeping build-generated files in the repository (while I'm pretty much for them in the tarballs from which usually distros create the packages).

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.

7 participants