Learning how to create and change configure scripts
 

I'm playing with configure scripts so I would like to learn how to create, modify and manage configure scripts.

I'm planning on creating a few apps in C and/or C++ so I would like to create the configure/make/make install scripts.

Amy good resources to get started, books and online resources would ne good.

Thanks

probably this: https://en.wikipedia.org/wiki/Configure_script

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.

Thanks guys, those wiki pages are good, but I'fd like to know about the configure script, in particular lets take these lines
If I wanted to build the app with x11grab enabled I think I can supply a switch like this:
Could I just remove the line instead?

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. :)

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.

Got to run.. honey does waiting ...
Cheers

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.

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!

Thanks to all of you who replied - great forum.

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

Cheers, have a nice day now