problem with subdir-objects and not found .Plo files when migrating to 1.14
Hi, I have a project that compiles perfectly under automake 1.11 and 1.12, but the scripts give warnings with 1.14, complaining that source file xyz is in a subdirectory, but option 'subdir-objects' is disabled. So, I simply enabled the above option, thinking that this would do the trick, however then I can't compile anymore, because .Plo files are not found, i.e.: toxcore/.deps/libtoxcore_la-DHT.Plo: No such file or directory Disabling automatic dependency tracking by adding the no-dependencies solves the problem, but I do not consider this a nice solution. From what I understand the subdir-objects feature will be required in 2.0, so as much as I would like to ignore it - I guess I'll have to find a clean fix for this issue, preferably one that would work with automake 1.11 and 1.14 (and later). My setup: I have two Makefile.am files, one on top level which is not doing much, except for EXTRA_DIST'ing a couple of things, it has one level of recursion, i.e SUBDIRS = build The build/Makefile.am includes a bunch of logically organized .inc files that list individual sources. The idea is that all object and all executable files go to the build directory. Yes, I do know that it is possible to build out of the tree to keep compiled files separate from the sources, however, especially during development, it is often more convenient to simply be able to type make at the top level, instead of having to navigate to some out of tree directory. If you'd like to have a look: https://github.com/jin-eld/ProjectTox-Core/tree/automake-portability Is it possible to keep the logic with the in-tree build directory with automake 1.14? I did try to move all the logic from build/Makefile.am into the top level Makefile.am and removing build/Makefile.am completely, but it does not help - .Plo files are not found. So right now I can either remove subdir-objects and I will get the warnings, or I can add it, but then the build fails. How do I solve this cleanly? Am I doing anything illegal or is it a limitaion or even a bug in 1.14? Kind regards, Jin
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
On Sat, Aug 31, 2013 at 11:50 PM, Sergey 'Jin' Bostandzhyan j...@mediatomb.cc wrote: Is it possible to keep the logic with the in-tree build directory with automake 1.14? I did try to move all the logic from build/Makefile.am into the top level Makefile.am and removing build/Makefile.am completely, but it does not help - .Plo files are not found. I'd say it's a very bad idea to use that build/Makefile.am. Move the includes on the top-level Makefile.am, and get rid of $(top_srcdir) on all the _SOURCES declaration and it should work fine. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
Hi, thanks for your reply, some more questions though: On Sun, Sep 01, 2013 at 03:08:37PM +0100, Diego Elio Pettenò wrote: Is it possible to keep the logic with the in-tree build directory with automake 1.14? I did try to move all the logic from build/Makefile.am into the top level Makefile.am and removing build/Makefile.am completely, but it does not help - .Plo files are not found. I'd say it's a very bad idea to use that build/Makefile.am. Could you please elaborate? I'd be interested in the technical details on why it is a bad idea? Move the includes on the top-level Makefile.am, and get rid of $(top_srcdir) on all the _SOURCES declaration and it should work fine. It does compile now, and it does dump all the .o and .lo and what not in the same directory as the sources - very ugly. This is exactly what I was avoiding with the separate build directory and it worked just perfectly until automake 1.14 came along. Is there any way to tell 1.14 to place the object files into some dedicated directory without doing an actual out of tree build, or in other words, can I achieve the same setup that I had on 1.14 somehow? Kind regards, Jin
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
Hi, OK, never mind, problem solved. It seems that $(top_srcdir) simply did not expand anymore in _SOURCES. Keeping my structure with the build/Makefile.am but replacing $(top_srcdir) with '..' did the trick, it works like a charm now, including in and out of tree builds. No more warnings, no more not found .Po files, and I get my binaries and libraries nicely in the build directory without polluting the source tree. Kind regards, Jin On Sun, Sep 01, 2013 at 06:45:32PM +0200, Sergey 'Jin' Bostandzhyan wrote: Hi, thanks for your reply, some more questions though: On Sun, Sep 01, 2013 at 03:08:37PM +0100, Diego Elio Pettenò wrote: Is it possible to keep the logic with the in-tree build directory with automake 1.14? I did try to move all the logic from build/Makefile.am into the top level Makefile.am and removing build/Makefile.am completely, but it does not help - .Plo files are not found. I'd say it's a very bad idea to use that build/Makefile.am. Could you please elaborate? I'd be interested in the technical details on why it is a bad idea? Move the includes on the top-level Makefile.am, and get rid of $(top_srcdir) on all the _SOURCES declaration and it should work fine. It does compile now, and it does dump all the .o and .lo and what not in the same directory as the sources - very ugly. This is exactly what I was avoiding with the separate build directory and it worked just perfectly until automake 1.14 came along. Is there any way to tell 1.14 to place the object files into some dedicated directory without doing an actual out of tree build, or in other words, can I achieve the same setup that I had on 1.14 somehow? Kind regards, Jin
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
Sergey, I'm curious as to why it's important to you that build products not land in the source tree, especially in light of the fact that you're clearly aware of automake's support for out-of-tree builds. Out-of-tree builds exist to solve the very problem you're trying so hard to fix. Be aware that you're kicking against the pricks (as the old saying goes). Sooner or later you'll run into other issues with new versions of automake that may not have such simple resolutions. Regards, John On Sep 1, 2013 11:53 AM, Sergey Jin' Bostandzhyan j...@mediatomb.cc wrote: Hi, OK, never mind, problem solved. It seems that $(top_srcdir) simply did not expand anymore in _SOURCES. Keeping my structure with the build/Makefile.am but replacing $(top_srcdir) with '..' did the trick, it works like a charm now, including in and out of tree builds. No more warnings, no more not found .Po files, and I get my binaries and libraries nicely in the build directory without polluting the source tree. Kind regards, Jin On Sun, Sep 01, 2013 at 06:45:32PM +0200, Sergey 'Jin' Bostandzhyan wrote: Hi, thanks for your reply, some more questions though: On Sun, Sep 01, 2013 at 03:08:37PM +0100, Diego Elio Pettenò wrote: Is it possible to keep the logic with the in-tree build directory with automake 1.14? I did try to move all the logic from build/Makefile.am into the top level Makefile.am and removing build/Makefile.am completely, but it does not help - .Plo files are not found. I'd say it's a very bad idea to use that build/Makefile.am. Could you please elaborate? I'd be interested in the technical details on why it is a bad idea? Move the includes on the top-level Makefile.am, and get rid of $(top_srcdir) on all the _SOURCES declaration and it should work fine. It does compile now, and it does dump all the .o and .lo and what not in the same directory as the sources - very ugly. This is exactly what I was avoiding with the separate build directory and it worked just perfectly until automake 1.14 came along. Is there any way to tell 1.14 to place the object files into some dedicated directory without doing an actual out of tree build, or in other words, can I achieve the same setup that I had on 1.14 somehow? Kind regards, Jin
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
John, On Sun, Sep 01, 2013 at 03:11:11PM -0600, John Calcote wrote: I'm curious as to why it's important to you that build products not land in the source tree, especially in light of the fact that you're clearly aware of automake's support for out-of-tree builds. Out-of-tree builds exist to solve the very problem you're trying so hard to fix. well, consider the following: your project has several source subdirectories, some of them with two levels. Even with out of tree builts you end up having the produced libraries and executables in each of those subdirectories respectively, or in other words: all over the place. Sure, you can do a make install to get all things together, but that's not always practical during development. My setup dumps all the compiled stuff into one directoriy, which makes it really easy to find, it's just more convenient. Honestly, if you have a choice, do you really prefer having the binaries all in different places in your tree? Also, I don't have to go out of the project dir when I want to make which I would have to do if I configured out of tree. What's wrong with that approach? People who use my setup seem to like it, as I said, it's convenience, no matter if used with in or out of tree builds. Be aware that you're kicking against the pricks (as the old saying goes). Sooner or later you'll run into other issues with new versions of automake that may not have such simple resolutions. I wonder why the authors of automake would try to restrict different and actually valid usage scenarios? I've been using this setup for over 5 years in different projects, I'd be really disappointed if I had to switch to a setup that is much more inconvenient for me. Please don't become another Gnome 3 by enforcing weird restrictions upon your users ;) Or is there really a hard technical limitation that would make setups as above impossible? I can't believe that... so I hope I will have the freedom of choice, also with newer versions of automake. Kind regards, Jin On Sep 1, 2013 11:53 AM, Sergey Jin' Bostandzhyan j...@mediatomb.cc wrote: Hi, OK, never mind, problem solved. It seems that $(top_srcdir) simply did not expand anymore in _SOURCES. Keeping my structure with the build/Makefile.am but replacing $(top_srcdir) with '..' did the trick, it works like a charm now, including in and out of tree builds. No more warnings, no more not found .Po files, and I get my binaries and libraries nicely in the build directory without polluting the source tree. Kind regards, Jin On Sun, Sep 01, 2013 at 06:45:32PM +0200, Sergey 'Jin' Bostandzhyan wrote: Hi, thanks for your reply, some more questions though: On Sun, Sep 01, 2013 at 03:08:37PM +0100, Diego Elio Petten wrote: Is it possible to keep the logic with the in-tree build directory with automake 1.14? I did try to move all the logic from build/ Makefile.am into the top level Makefile.am and removing build/Makefile.am completely, but it does not help - .Plo files are not found. I'd say it's a very bad idea to use that build/Makefile.am. Could you please elaborate? I'd be interested in the technical details on why it is a bad idea? Move the includes on the top-level Makefile.am, and get rid of $ (top_srcdir) on all the _SOURCES declaration and it should work fine. It does compile now, and it does dump all the .o and .lo and what not in the same directory as the sources - very ugly. This is exactly what I was avoiding with the separate build directory and it worked just perfectly until automake 1.14 came along. Is there any way to tell 1.14 to place the object files into some dedicated directory without doing an actual out of tree build, or in other words, can I achieve the same setup that I had on 1.14 somehow? Kind regards, Jin
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
On Sun, Sep 1, 2013 at 10:36 PM, Sergey 'Jin' Bostandzhyan j...@mediatomb.cc wrote: I wonder why the authors of automake would try to restrict different and actually valid usage scenarios? I've been using this setup for over 5 years in different projects, I'd be really disappointed if I had to switch to a setup that is much more inconvenient for me. Because trying to be clever and special with build systems is a bad way to make a build system. Distributions will dislike you and it's much less likely that they'd like to package your software. If I were to find any problem with the build system of your project, I would stop looking the moment I find the silly build directory, and decide that it's not worth packaging at all. Don't be special, don't be clever. Use out-of-tree build if you want and behave consistently with other projects. Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
Don't get me wrong - I have nothing against your approach. And the automake maintainers are certainly not purposely trying to make things more difficult for you. I merely suggest that you may run into more issues down the road simply because supporting your setup is not a current goal of the tool. Indeed, I've found these guys to be quite amenable to adding new build paradigms to automake's repertoire. I'm glad you found a solution that works. On Sep 1, 2013 3:36 PM, Sergey 'Jin' Bostandzhyan j...@mediatomb.cc wrote: John, On Sun, Sep 01, 2013 at 03:11:11PM -0600, John Calcote wrote: I'm curious as to why it's important to you that build products not land in the source tree, especially in light of the fact that you're clearly aware of automake's support for out-of-tree builds. Out-of-tree builds exist to solve the very problem you're trying so hard to fix. well, consider the following: your project has several source subdirectories, some of them with two levels. Even with out of tree builts you end up having the produced libraries and executables in each of those subdirectories respectively, or in other words: all over the place. Sure, you can do a make install to get all things together, but that's not always practical during development. My setup dumps all the compiled stuff into one directoriy, which makes it really easy to find, it's just more convenient. Honestly, if you have a choice, do you really prefer having the binaries all in different places in your tree? Also, I don't have to go out of the project dir when I want to make which I would have to do if I configured out of tree. What's wrong with that approach? People who use my setup seem to like it, as I said, it's convenience, no matter if used with in or out of tree builds. Be aware that you're kicking against the pricks (as the old saying goes). Sooner or later you'll run into other issues with new versions of automake that may not have such simple resolutions. I wonder why the authors of automake would try to restrict different and actually valid usage scenarios? I've been using this setup for over 5 years in different projects, I'd be really disappointed if I had to switch to a setup that is much more inconvenient for me. Please don't become another Gnome 3 by enforcing weird restrictions upon your users ;) Or is there really a hard technical limitation that would make setups as above impossible? I can't believe that... so I hope I will have the freedom of choice, also with newer versions of automake. Kind regards, Jin On Sep 1, 2013 11:53 AM, Sergey Jin' Bostandzhyan j...@mediatomb.cc wrote: Hi, OK, never mind, problem solved. It seems that $(top_srcdir) simply did not expand anymore in _SOURCES. Keeping my structure with the build/Makefile.am but replacing $(top_srcdir) with '..' did the trick, it works like a charm now, including in and out of tree builds. No more warnings, no more not found .Po files, and I get my binaries and libraries nicely in the build directory without polluting the source tree. Kind regards, Jin On Sun, Sep 01, 2013 at 06:45:32PM +0200, Sergey 'Jin' Bostandzhyan wrote: Hi, thanks for your reply, some more questions though: On Sun, Sep 01, 2013 at 03:08:37PM +0100, Diego Elio Petten wrote: Is it possible to keep the logic with the in-tree build directory with automake 1.14? I did try to move all the logic from build/ Makefile.am into the top level Makefile.am and removing build/Makefile.am completely, but it does not help - .Plo files are not found. I'd say it's a very bad idea to use that build/Makefile.am. Could you please elaborate? I'd be interested in the technical details on why it is a bad idea? Move the includes on the top-level Makefile.am, and get rid of $ (top_srcdir) on all the _SOURCES declaration and it should work fine. It does compile now, and it does dump all the .o and .lo and what not in the same directory as the sources - very ugly. This is exactly what I was avoiding with the separate build directory and it worked just perfectly until automake 1.14 came along. Is there any way to tell 1.14 to place the object files into some dedicated directory without doing an actual out of tree build, or in other words, can I achieve the same setup that I had on 1.14 somehow? Kind regards, Jin
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
On Sun, Sep 01, 2013 at 10:53:26PM +0100, Diego Elio Pettenò wrote:
I wonder why the authors of automake would try to restrict different and
actually valid usage scenarios? I've been using this setup for over 5
years
in different projects, I'd be really disappointed if I had to switch to a
setup that is much more inconvenient for me.
Because trying to be clever and special with build systems is a bad way to
make
a build system. Distributions will dislike you and it's much less likely that
they'd like to package your software.
If I were to find any problem with the build system of your project, I would
stop looking the moment I find the silly build directory, and decide that
it's not worth packaging at all.
Interesting opinion, however, just an opinion and not a fact. I've been
using the same build approach in MediaTomb and we got packaged for almost
all available distros. Not once have I heard complaints about the build
directory, and why should I anyway? Packagers don't care about things like
that as long as make install works properly and respects ${prefix}.
Besides that, their most trouble is usually finding dependencies which
are in different places on different distros, and that piece of magic is in
autoconf/configure anyway.
Don't be special, don't be clever. Use out-of-tree build if you want and
behave
consistently with other projects.
Well, so far I have not heard a single technical argument on why I should
not be doing things that way.
Very bad idea and don't be special qualify for arguments of personal taste,
and that's what I love Linux for: it gives you the freedom to do things the
way that is most productive to _you_. Actually, if noone was ever clever and
special we'd probably be using MS DOS.
Consistency - maybe - but if *imho* the default way is consistently
inconvenient, why should I be following it within my projects? As long as
I don't break the rules to the outside, i.e. have a properly working
make install / make dist / out of tree build support - I don't see why I
should not be allowed to organize my build they way that suits me most within
my tree.
And it's not like I am hacking automake and doing weird things with custom
make targets etc., I'm using the default feature set that is provided, what's
wrong with that?
That being said, I have the feeling that this discussion does not lead
anywhere, I was hoping to hear some technical arguments on why it is bad
to have a build setup like I do, but so far I have not heard any.
I'd like to thank you once again for your initial reply as it did help me
to overcome the problem that I originally had.
Kind regards,
Jin
Re: problem with subdir-objects and not found .Plo files when migrating to 1.14
On Sun, Sep 1, 2013 at 11:27 PM, Sergey 'Jin' Bostandzhyan j...@mediatomb.cc
wrote:
Interesting opinion, however, just an opinion and not a fact.
An opinion of a distro packager who's been dealing with similar stuff for
years...
I've been
using the same build approach in MediaTomb and we got packaged for almost
all available distros. Not once have I heard complaints about the build
directory, and why should I anyway? Packagers don't care about things like
that as long as make install works properly and respects ${prefix}.
You have a very naïve idea of how packaging works. And if you didn't hear
any complain it means you haven't listened very carefully. Given I actually
was the original packager for mediatomb for Gentoo, and that I did so
because there was no alternative, I'm pretty sure I know what I'm talking
about. It's not a coincidence that I dropped it quite quickly.
Well, so far I have not heard a single technical argument on why I should
not be doing things that way.
Very bad idea and don't be special qualify for arguments of personal
taste,
and that's what I love Linux for: it gives you the freedom to do things the
way that is most productive to _you_. Actually, if noone was ever clever
and
special we'd probably be using MS DOS.
Yadda yadda. You haven't given a technical argument for your choice either.
It's just aesthetics and convenience for your make command. While on the
other hand you have consistency for the people that cater your software to
users.
You want technical? As you can see by the warnings issued by automake 1.14,
non-subdir-objects build are going to go away at some point because they
require much more maintenance than it's worth, just because of aesthetics,
isn't that enough? I would also add that you're trying to be clever with a
build system while not really groking it, which is more than dangerous.
Good luck, but definitely I'll mark down your project as a do not go
near. I've had enough headaches with mediatomb.
