Source control and Anjuta project

Applications
1

Hi, ALL,
I have 2 machines with Linux installed - one is a little older and one is newer.

I also have Anjuta installed for developing my project.

I started with an older one where I have autotools version 1.15. and when I created a project in Linux I put everything Anjuta made in source control (GitHub).

Now I made a newer Linux box, installed Anjuta, cloned my project and tried to compile.
Unfortunately it failed the compilation, because the new box contains autotools version 1.16.

I did run “autoreconf -if”, it updated the files and now compilation is going, but this makes me curious - what files that Anjuta created should not be in source control because they depend on the system tools version.

Now, if Anjuta is capable of running “autoreconf” - great. But still this command will change some files in the project directory, so maybe some files shouldn’t be in source control?

Thank you.

2

Please check Autotools FAQ

Also I would recommend not using autotools in 2021, but that might need you to switch to another IDE

1 Like
3

4 posts were split to a new topic: Autotools recommendations

4

@jensgeorg ,
Why do I need to switch from Autotools? What is so bad about them?
Are you proposing CMake? Or any other Makefile-generation tool?

I know CMake is turning autotools down, but a huge number of software still uses autotools and don’t plan on switching, so why should I?

Any OS tools is using autotools. I believe FF/Chrome are using it.
A lot of useful Linux utilities are using autotools.

Can you point me to any popular software that doesn’t?

Thank you.

5

I believe FF/Chrome are using it.

I’m not sure if you’re trolling, or confused. I’m going to assume the latter.

Firefox uses Autoconf, but it’s stuck on a 20-year-old version. The bug report to upgrade to a modern version of Autoconf had been open since 2001 until it was WONTFIXed earlier this year. It does not use Automake: instead, it has a custom buildsystem that I’ve never heard of before, Mach. I don’t know anything about that.

I have no clue why you think Chromium uses Autotools. It used to use gyp, which was written for Chromium. Nowadays it uses gn, which was also written for Chromium.

Can you point me to any popular software that doesn’t?

GNOME uses Meson. systemd uses Meson. KDE uses CMake. WebKit uses CMake. Etc. etc. etc. You are on discourse.gnome.org, so you’re likely to find proponents of Meson here.

The accepted, commonly-held opinion here is that Autotools is really bad. Anyone who has been working on GNOME for longer than five years is likely very familiar with autoconf, automake, libtool, etc. and they were not very fun. We do not want to go back.

That said, discussion is pointless because everyone has their own opinions. Only thing certain is Autotools is way better than hand-rolled Makefiles.

1 Like
6

I didn’t say you need or have to. You can do whatever you want. Autotools is like food that is past its “best before” date. It might still be good for you, or can cause you severe stomach ache and excessive vomiting. If it is fine for you, by all means, do what you like. the linked autools FAQ should tell you which files should belong in your repository and which not.

7

BTW the successor to Anjuta is Builder. Anjuta hasn’t seen any development beyond build fixes and translation updates in the past 2.5 years. You’re not likely to find serious help for it here, because nobody is familiar with it anymore. Good luck anyway.

That sounds like an Automake version. “Autotools” is a bunch of different projects with their own version numbers.

With Autotools, you want to commit the original source files only (autogen.sh, configure.ac, Makefile.am, certain m4 scripts), and you don’t want to commit generated files (everything else). You should be using git.mk to generate your .gitignore files, which will help with this. Adding generated files to source control is almost always a mistake.

8

Hi,

I think for Autotools you need to put in source control: configure.ac, autogen.sh and all Makefile.am. Then AUTHORS, ChangeLog, NEWS, README, COPYING and po directory is needed for a GNU source project, and *.anjuta for the Anjuta itself. You shouldn’t put other files in particular configure, Makefile and Makefile.in files

Else, I have not enough time anymore to work on Anjuta so the development is stuck and I don’t foresee any improvement unless other people want to work on it.

Regards,

9

Sebastien,
Here is the list of files that was changed after I ran autoreconf.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   INSTALL
        modified:   Makefile.in
        modified:   aclocal.m4
        modified:   config.guess
        modified:   config.sub
        modified:   configure
        modified:   dbhandler/Makefile.in
        modified:   dbinterface/Makefile.in
        modified:   install-sh
        modified:   libdbloader/Makefile.in
        modified:   libdbwindow/Makefile.in
        modified:   libdialogs/Makefile.in
        modified:   libfieldswindow/Makefile.in
        modified:   libmysql/Makefile.in
        modified:   libodbc/Makefile.in
        modified:   libpostgres/Makefile.in
        modified:   libpropertieshandlers/Makefile.in
        modified:   libpropertypages/Makefile.am
        modified:   libpropertypages/Makefile.in
        deleted:    libpropertypages/gtk/fontpropertypage.cpp
        deleted:    libpropertypages/gtk/fontpropertypage.h
        modified:   libshapeframework/Makefile.in
        modified:   libshapeframework/ShapeCanvas.cpp
        modified:   libsqlite/Makefile.in
        modified:   libtabledataedit/Makefile.in
        modified:   libtablewindow/Makefile.in

Can you check and see whether all of them should be excluded? All “lib*” stuff are dynamically linked libraries (*,so)

Thank you.

10

@mcatanzaro ,

I did see the Builder. I installed it to try but unfortunately it doesn’t have a template to create a project for the library I’m using (wxGTK).

Asking about it on the Builder forum I got a reply that its not a GTK/wxWidgets thing and so will not be added/supported unless someone will have a patch for it.

So for the time being I will have to stick with Anjuta and Autotools.

Thank you for the suggestion though - duly noted. :wink:

11

I searched for your post but didn’t found it. Which Builder forum is meant by you?

Anyway - its true that we don’t have wxWidgets templates and this is for sure not our priority. But still you can use Builder with all projects variants imagineable. Heck you can even build Inkscape or FreeCAD without configuring anything. So i think it should work for wxWidgets project too.

12

All of the non-cpp/h files should be ignored, yes. Your problem is you ignored my previous advice to use git.mk. You really need to use git.mk if you want to do this properly. It will handle all of this for you if you follow the instructions.

If the .cpp/.h files are generated, then they need to be ignored too. If they’re really generated by autoreconf and not by configure – that is, if they’re generated by the maintainer and distributed with your project tarball, not built by the end user who only runs configure and not autoreconf – then they need to be added to MAINTAINERCLEANFILES as well. That seems weird for .cpp/.h files, though, so I am very suspicious of that. .cpp/.h files are usually generated by make and belong in normal CLEANFILES (except for config.h, which is always generated by configure), but for some reason that appears to not be the case for you, which is suspicious. Assuming the information you provided is correct, your build system might be doing something weird/wrong.

Remember this advice from Autotools 101:

  • MOSTLYCLEANFILES exists, but I recommend ignoring it, because it’s mostly not useful
  • CLEANFILES is for things generated by make
  • DISTCLEANFILES is for things generated by configure
  • MAINTAINERCLEANFILES is for things generated by autogen.sh/autoreconf

git.mk will add all of the above to the .gitignore that it generates. If generated files are missing from the .gitignore, it means you messed up the *CLEANFILES. Also remember that because .gitignore is itself generated by make, it is itself going to be ignored. Do not try to commit it.

I’m going to insist that git.mk is the only reasonable way to integrate Autotools with git. Getting that all correct manually and keeping your *CLEANFILES synchronized with your .gitignore without the assistance of git.mk would be error-prone and pointless.

P.S. You should really use Meson instead, which is GNOME’s recommended replacement for Autotools, but we have another thread for that discussion now.

13

One more thing. If you insist on making your life harder by using Autotools instead of Meson, I’m going to recommend that you should understand the basics of how it works. Pick up a copy of the Autotools book by John Calcote, and read it cover to cover over the next few days. The questions you’re asking are very basic: if you know that Makefile.in is generated from Makefile.am, and you know that you don’t want to commit generated files, then you know it should be ignored. You’re missing one or the other, and either way you have a some serious learning to do. :wink: I don’t consider this book a good reference for best practices, but it is a good introduction that will help you become comfortable with the basics.

After that book, the next step is to read https://autotools.io/ a couple times learn the best practices, and refer back to that website whenever needed. This website is not a good introduction, but it is a good reference.

14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.