What does subdir-objects do?
Hi,
I'm having trouble understanding what the subdir-objects option does. The
project I'm building [1] prints a warning when building without
subdir-objects:
libgd/Makefile.am:29: warning: source file 'libgd/gd-types-catalog.c' is in
a subdirectory,
libgd/Makefile.am:29: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the
'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding
output
automake: object file(s) will be placed in the top-level directory.
However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same
subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout
your
automake: project, to avoid future incompatibilities.
My understanding (based on [2]) is that subdir-objects changes where the
generated object files are placed, so I tried the following:
git checkout with-subdir-objects
git clean -dfx
./autogen.sh
make
find . > /tmp/with-subdir-objects-tree
git checkout without-subdir-objects
git clean -dfx
./autogen.sh
make
find . > /tmp/without-subdir-objects-tree
diff /tmp/with{,out}-subdir-objects-tree
The diff found 0 different lines, so I guess I'm missing something. What
exactly does subdir-objects do?
Thanks,
Kerrick
[1] The project is gnome-boxes: http://git.gnome.org/gnome-boxes
[2]
http://www.gnu.org/software/automake/manual/html_node/List-of-Automake-options.html#index-subdir_00http://git.gnome.org/gnome-boxes2dobjects
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: What does subdir-objects do?
On Sat, Aug 31, 2013 at 11:36 PM, Kerrick Staley
wrote:
> git checkout with-subdir-objects
> git clean -dfx
> ./autogen.sh
> make
> find . > /tmp/with-subdir-objects-tree
> git checkout without-subdir-objects
> git clean -dfx
> ./autogen.sh
> make
> find . > /tmp/without-subdir-objects-tree
> diff /tmp/with{,out}-subdir-objects-tree
>
> The diff found 0 different lines, so I guess I'm missing something. What
> exactly does subdir-objects do?
>
You're using git submodules, so your git clean -dfx is not working properly.
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
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" 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" 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 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" 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" > 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 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.
