[SOLVED] Learning how to create and change configure scripts
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The link posted by pan64 is an excellent place to start.
In that page you will find a link to the GNU Autoconf page, be sure to follow it. Finally, in that page you will find a list of Related Software. You will need to refer to the GNU M4 macro language and macros plus Automake for the full picture.
With autotools you should normally not directly edit the configure script or any of the Makefile.in files and should only touch the configure.ac and Makefile.am files. These are used to generate configure and the Makefile.in files with tools like autoreconf.
That's why I posted that wiki page and that's why were the auto* tools mentioned (because the file itself is generated).
Obviously you can modify that file and test if that works, but that is not the "official" way (unfortunately it is not that simple, but in some cases it may work).
I have been busy editing the "configure" for few reasons.
I do not have theoretical knowledge about the "auto" processes creating the "configure", and after looking at the wiki "flowchart" I am not so sure I want to dig into it at this point.
After all my objective was not to analyse "configure" but use it with desired options.
Being opinionated, I believe one has to assume that some processes just do what they are designed to do and I find it unnecessary to "start from Adam".
"running" configure script is rudimentary and after figuring out the "innards" it is pretty strait forward to make MINOR changes and verify them.
I am not so sure if same can be done by modifying the "autox" processes.
At least it would be two step process and the "configure" would still have to be optioned to provide necessary debugging data. ( yes I use the log file )
On the lighter site - I find it "humorous" to see footprints of different developer's coding methods, some code is pretty obvious some pretty obfuscated.
Bottom line - when "configure" works - no problema, but when it fails it is a challenge.
Cheers
There are some projects which do just as you suggest and modify configure and makefile.in files manually and sometimes they are handwritten (While still using autotools), these solutions are often half broken and very hard to work with. If you intend for other people to use your work, please don't do this! Of course, lot of things can be learned from reading and understanding these auto-generated files.
There are some projects which do just as you suggest and modify configure and makefile.in files manually and sometimes they are handwritten (While still using autotools), these solutions are often half broken and very hard to work with. If you intend for other people to use your work, please don't do this! Of course, lot of things can be learned from reading and understanding these auto-generated files.
Just out of curiosity.
I see similar comments pretty often.
I generally feel Internet forums are not where professional developers take their questions.
When I was paid to do product QA , evaluating software, I consulted the fellow ,also paid, employees.
Based on this assumption - why would "amateur developer" even consider his /her work to be of benefits to public by considering all "if this then what" situations?
But on similar note - anybody who inspire to make public happy should at least comment their ware.
If you intend for other people to use your work, please don't do this! Of course, lot of things can be learned from reading and understanding these auto-generated files.
Thanks for your reply.
I don't intend anyone else apart from myself to use my work, so if I break it it only affects me.
That's why I posted that wiki page and that's why were the auto* tools mentioned (because the file itself is generated).
Obviously you can modify that file and test if that works, but that is not the "official" way (unfortunately it is not that simple, but in some cases it may work).
I find the only way to really learn how something works is to do it manually.
I know about the auto* tools, I know what they're for, but I'm experimenting and playing with the code to understand it. I know I may break something, but you can't bake a cake without breaking a few eggs. That's why I want to edit the configure script - to learn how it works!
I find the only way to really learn how something works is to do it manually.
That is an interesting question. From one side you need to learn how does it really [planned to] work, and that means you need to understand the toolset.
From the other hand you are right, if you want to go into details (deep inside).
Quote:
Originally Posted by GPGAgent
I know about the auto* tools, I know what they're for, but I'm experimenting and playing with the code to understand it. I know I may break something, but you can't bake a cake without breaking a few eggs. That's why I want to edit the configure script - to learn how it works!
The question is: How can you accept if the constructed file actually works, but cannot be generated?
That is an interesting question. From one side you need to learn how does it really [planned to] work, and that means you need to understand the toolset.
From the other hand you are right, if you want to go into details (deep inside).
The question is: How can you accept if the constructed file actually works, but cannot be generated?
Well obviously if I can construct something that works it's good, the fact it cannot be generated is of no consequence
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.