Comments (5)
For a series of small commits, it's OK to not re-generate "configure", etc. I don't understand why you'd need to re-generate them for small commits.
from freeradius-client.
Take an example. These two pull requests are independent and can be applied on current master.
#32
#31
However, they cannot be applied on top of each other because they both modify configure. Even though they are not so small, each patch which adds a file in Makefile.am or modifies configure.in will conflict with any other small or big patch which modifies the same file.
As it is now, it is easy to submit patches which modify only source code files. Modifying a Makefile.am or configure.in, will cause a conflict somewhere.
from freeradius-client.
On Dec 18, 2014, at 11:00 AM, Nikos Mavrogiannopoulos [email protected] wrote:
Take an example. These two pull requests are independent and can be applied on current master.
#32
#31However, they cannot be applied on top of each other because they both modify configure.
As I said, it’s OK to have commits which don’t do that. Sure, it won’t build in the short term. But who cares, you can always have a final commit of “re-generate configure”. Which includes all of the configure changes.
Even though they are not so small, each patch which adds a file in Makefile.am or modifies configure.in will conflict with any other small or big patch which modifies the same file.
As it is now, it is easy to submit patches which modify only source code files.
Then do that.
Modifying a Makefile.am or configure.in, will cause a conflict somewhere.
No. re-generating files will cause a conflict. So… don’t do that.
For example, in pull #31, you re-generate “configure”. Why? The configure.in script isn’t changed. So I don’t understand why it’s necessary to re-generate configure.
And adding scripts like “compile”, which is a “Wrapper for compilers which do not understand '-c -o’” Really? It’s almost 2015. If the compiler doesn’t work, the user should install a better compiler.
I don’t see why I should butcher the software and build scripts to deal with broken systems that can’t build binaries.
I just don’t get why there’s a need to butcher everything to make a small change in the code.=
from freeradius-client.
Modifying a Makefile.am or configure.in, will cause a conflict somewhere.
No. re-generating files will cause a conflict. So… don’t do that.
In pull request #26 Arran asked for the auto-generated files to be included and were included in #30.
And adding scripts like “compile”, which is a “Wrapper for compilers which do not understand '-c
-o’” Really? It’s almost 2015. If the compiler doesn’t work, the user should install a better compiler.
I don’t see why I should butcher the software and build scripts to deal with broken systems that
can’t build binaries.
I believe you understand that these are being added by autogen, and not by me. If I have to regenerate those files, it will be using the autogen in my system.
I just don’t get why there’s a need to butcher everything to make a small change in the code.
I don't understand if you refer to the changes by autogen or me. If you refer to the autogen changes, that is the reason no github projects include the auto-generated files. If it is the changes by me I don't like that. Do you expect contributions in the project or not? I take the effort to provide back changes, if you don't need them, I shouldn't bother either.
from freeradius-client.
On Dec 18, 2014, at 11:21 AM, Nikos Mavrogiannopoulos [email protected] wrote:
Modifying a Makefile.am or configure.in, will cause a conflict somewhere.
No. re-generating files will cause a conflict. So… don’t do that.
In pull request #26 Arran asked for the auto-generated files to be included and were included in #30.
For small changes, yes. If you’re making dozens of changes and re-generating the files, no. It causes problems, as you discovered.
The solution is to skip the autogen step until you’re done the changes.
And adding scripts like “compile”, which is a “Wrapper for compilers which do not understand '-c
-o’” Really? It’s almost 2015. If the compiler doesn’t work, the user should install a better compiler.
I don’t see why I should butcher the software and build scripts to deal with broken systems that
can’t build binaries.I believe you understand that these are being added by autogen, and not by me. If I have to regenerate those files, it will be using the autogen in my system.
Which is why I hate autogen and autoconf. They produce tons of meaningless and useless crap.
I just don’t get why there’s a need to butcher everything to make a small change in the code.
I don't understand if you refer to the changes by autogen or me.
autogen. Which is why I said to not re-generate the files on every tiny commit.
If you refer to the autogen changes, that is the reason no github projects include the auto-generated files.
No. LOTS do.
If it is the changes by me I don't like that. Do you expect contributions in the project or not? I take the effort to provide back changes, if you don't need them, I shouldn't bother either.
I like changes from people. I don’t like thousands of lines of auto generated crap. That makes it more difficult to see what YOU changed, which means it’s less likely that YOUR contributions will be added.
Please commit YOUR changes. Not the autogen ones. I can run autoconf myself.=
from freeradius-client.
Related Issues (20)
- Encryption of CHAP-password HOT 2
- BUG: Dictionary attributes compared against UINT8_MAX HOT 3
- dictionary.sip cannot be used due to large attibute values HOT 5
- Is there a Java version for freeradius? HOT 1
- Does freeRadius support EAP_AKA? HOT 1
- I want use OTP two factor authentication HOT 2
- Does this library has plan to support windows ? HOT 1
- User-password and shared secret limits too low, should be 128. HOT 2
- configure.in contains a check that isn't C99 compliant as it's main function lacks a return type.
- Is there an openwrt package HOT 1
- Error in 1.1.8 when there is no entry for radius port in /etc/services HOT 1
- srandom() not called HOT 1
- new release? HOT 19
- rc_avpair_tostr() crashes on bad PW_TYPE_DATE data HOT 1
- freeradius-clinet that supports PAM & PEAP/TLS-EAP HOT 1
- getaddrinfo memory leaks
- attribute issue with windows using dictionary.microsoft after successful connection in PPTP HOT 1
- Accounting only configuration HOT 3
- Freeradius Mssql DB HOT 1
- Facing Issue While Vendor Specific Configuration HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from freeradius-client.