A bit of background: I am trying to update a program that I wrote some years ago. It had a bad bug in it, which I think I have corrected now. So I want to rebuild it completely with a new version number.

The problem is that autotools have moved on a lot since those days and frankly I never really understood them the first time around. I was able to run aclocal, autoconf and automake without problems, once I had renamed configure.in to configure.ac (I have no idea why it asked me to do that!)

Then I ran configure and make. Make crashed with the message:
The src directory contains a number of .c files including ui.c, but no .Po files. I have only a vague idea what those are, though I have noticed them when building other people's software. It's something to do with internationalisation, isn't it?

Basically I need to know how to create these .Po files, since the Makefiles created with recent autotools seems to require them. I'm not using gettext by the way.

PS: I've found a gettext manual which looks like it should explain this but I am finding it hard going. And my program doesn't use any gettext functions so why am I getting chased for .Po files?

Hazel, I use internationalization in my programs, although not with gettext. However, the po-file helps just to map your string-output to be translated in any of the supported languages... or those, for which translations have been provided (in a po-file).

If you did not use gettext in your program, why not just touch the deps/ui.po file that your compiler complains about. If there is nothing to translate, nothing should bother for the content of the file. At least.., I would be interested in the next error message that this might provoke.

Alternatively, wait for the next contribution, below mine.

I've been trying to gettextise it following the GNU gettext manual. I think I have got into a complete mess. The gettext commands listed in the manual have created a Po directory containing a file called en_GB.po, but not the individual .deps/*.po files for the source code (for example ui.po for ui.c). And I can't find out where those files are supposed to come from. I only know that when make is run, it expects them to be already there.

OK, so I faked them all, one for each source file as suggested. And Make actually got going with the compilation, then crashed because it couldn't find LOCALEDIR (which I only put into the code because the gettext manual said I should!).

Well, after much faffing around, I discovered several things:

1) The GNU gettext manual is seriously out of date. You need to cross-check anything it says about autoconf or automake by looking in those manuals, which are more recent.

2) The empty source_file.po files that I created in src/.deps (as per Michael's suggestion) got filled up during the build with lists of all the headers which those source files use directly or indirectly. So that answers the question about what they are, which is why I have marked this thread as solved. I still don't know why make refuses to create them from scratch, or what on earth those headers have to do with nls support.

3) The "bug" I wanted to correct, which sparked off all this kerfuffle, seems to have become much worse as a result of my correction. I'll have to study the logic of that part of the program again.

PS: This time I have found it .

Issues like this are why I always say that when it comes to 'autotools' the cure is worse than the disease!

I'd rather just maintain my makefiles "the hard way", which it turns out, is often a much easier way.

So now I have another problem! Having debugged the program, I ran "make distcheck" to create the package. And guess what! It crashed because it couldn't find those damned source.Po files. They exist in src/.deps, which is where a normal make looks for them. They exist there because I put them there by hand. But make distcheck looks in a temporary location called build/sub/src/.deps and then complains that it has no rules for creating them.

So does your program now actually need gettext? Because if not, I would suggest backing up and figuring out why make thinks the .Po files are needed (e.g., maybe you just need to disable some option in automake to stop it). Creating what are supposed to be auto-generated files by hand is just asking for trouble.

I've discovered that there are two completely different sorts of po files. Those that carry the .po extension are gettext catalogues and live in the po directory. The .Po files are lists of headers on which the package is dependent and they are found in src/.deps. They have nothing to do with gettext so that was a blind alley. Though I suppose that internationalising my package with gettext was quite a useful thing to do anyway.

The .po dependency files look as though they should be created by a script called depcomp, which itself is created by automake. I have no idea why it isn't working in my package. I entirely agree that cheating by inserting things by hand is not a final answer. It allowed me to compile a version for testing, debugging and installation, but I now need to somehow get it to happen by itself.

If anyone can give me the key to that, I'd be grateful.

I don't have experience with gettext, but I see the manual mentions something called autopoint, which is apparently needed to setup the autotool stuff for gettext

https://www.gnu.org/software/gettext...nvocation.html

Assuming you're putting these in the plugin's languages directory, then you would not use get_template_directory().

OK, ntubski, I'll try that out when I next boot LFS. Can't do it now because I'm in Slackware and the 14.2 version of autotools is definitely too old. But if you look at my last post again, you'll see that gettext is no longer the problem. I was confused before (wrong kind of po file!).

Sorry, amyakar, but I don't get your point. Can you explain?

I have now found out where these .Po files are supposed to come from. They are specified in src/Makefile as follows:
I can partly decipher this. DEPDIR is the directory src/.deps. It looks as if the first line compiles source files and creates some .Tpo files containing the names of headers on which the program depends. Then they get renamed to .Po (am__mv turns out to be code for mv -f).

So it is not true that there is no rule to make these. There is a rule but it's not being observed. Interestingly, this makefile also sets the LOCALEDIR variable (which the build refused to recognise) as follows:
So why is this not working? What blindingly obvious thing am I not seeing?

Until some upstream ends up with a brittle, non-portable and broken build system which the developers do not see any issues with since it works on their system. Of course the same does happen to autotools sometimes too, but I personally don't see it as often.

From make's point of view, that isn't a rule to make .Po files. It's a rule to make a .o given a .c file, which happens to additionally produce a .Po file as a side-effect (but make doesn't analyse the details of shell commands so it's unaware of this side-effect). Perhaps just deleting all the .o files and rebuilding will do the trick?

Somewhere in this process of ill-conception, the autotools should breach in, from my understanding of “things”.

While I use autotools for building and am rarely confronted with their misbehavior, the hurdle race, which Hazel describes, does recall all those occasions, when a developer had to “guess” or to “suggest” potential solutions to my own problems with aclocal and the like.

The Qt framwework that I principally use for my C++ programming rather imposes their QMake as build-system. I am not proud of my lack of autotools knowledge, but this thread rather confirms all my previous decisions to ignore them.

Could the end of the discussion be a suggestion for improvement, if not a bug-report? The documentation is oftentimes brought up, when an open-source system fails to work out of the box, but maintaining manuals is never the main interest of a developer. This specific problem of the autotools and others is difficult to handle.