This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
Le 23/09/2011 21:43, Jeff Squyres a écrit :
> On Sep 23, 2011, at 3:40 PM, Brice Goglin wrote:
>>> Is there a reason to not have it as an .am? I don't really care other than uniformity, I think -- if there's just *one* Makefile that's different, it's one more thing that has to be remembered, etc.
>> The easiest way to make it a .am would be to add this directory to
>> SUBDIRS but use rules names that are not recognized by automake (so that
>> "all" does nothing). It's probably already the case (current rules are
>> "missing" and "useless", with a common dependency called "prepare"). If
>> you're confident that those will never conflict with automake, I can
>> make this a Makefile.am and we're done.
> Just because you have a Makefile.am (and therefore generated Makefile.in / Makefile), you don't have to list that dir in SUBDIRS. So "make all" will never traverse down there, etc.
AFAIK configure will not generate Makefile[.in] unless the dir is in
SUBDIRS. Otherwise we would have Makefile[.in] generated in
tests/embedded (I don't have any).