Re: Help Requests
On Tue, 2003-12-09 at 14:32, dc wrote: AFAIK There's a third possibility : you could setup a dist-hook target in Makefile.am which allows you to specify completely your dist rule (I had the same problem than yours and used this method). Unfortunately, it also means that you might have to update this rule each time you change metadata in your source tree. Thanks for the response. After a bit of a long holiday break, I am back trying to get this to work. As a quick review, my Makefile.am is not located in the top-level of my directory structure and is causing a problem with make dist. Changing this structure is beyond my control, so I'm stuck with what's there. Therefore, I've tried a number of attempts at writing a dist-hook as suggested above. However, I have again run into problems. When I run make dist, it populates the distdir, but due to the use of manual VPATHs (i.e. ../..), what it actually populates is above the distdir - all that ends up in this directory is the DIST_COMMON stuff. So, my plan is to have the dist-hook delete the mess created by the VPATH stuff, and then copy the necessary files into the distdir manually before it gets tarred up (if there is a better way to approach this, please advise). Here is an example of my attempt: ISRC = $(srcdir)/../../include [snip] dist-hook: rm -rf $(distdir)/$(ISRC) \ mkdir $(distdir)/include \ cp -pR $(ISRC) $(distdir)/include Now, the rm command deletes as expected, but the mkdir and cp don't seem to do anything. As before, I only end up with a tar.gz of the DIST_COMMON files, which are the only files in the distdir. Does anyone have a suggestion on how to proceed, or perhaps someone could point out the flaw in my reasoning? Thanks very much! Best Regards, Scott /// didier Le mar 09/12/2003 21:19, J. Scott Amort a crit : Thanks for the response! On Tue, 2003-12-09 at 08:05, Thien-Thi Nguyen wrote: i see from the previous post that you use a manual VPATH methodology. there are two approaches you can try: 1/ undo the unorthodoxy (move auto* files to top-level dir) 2/ prefix relative paths (such as ../../) w/ $(srcdir) I gave #2 a try, and it didn't change the output of make dist. However, moving everything into the top-level dir (#1) did solve the problem. Unfortunately, I don't currently have any control over the directory structure (the motivation behind the attempt is to keep platform specific items, i.e. *nix makefiles, VC++ 6 project files, etc. in subdirectories away from the source files). I'll speak to the powers that be and see about getting this changed. Thanks again.
Re: Help Requests
i see from the previous post that you use a manual VPATH methodology. there are two approaches you can try: 1/ undo the unorthodoxy (move auto* files to top-level dir) 2/ prefix relative paths (such as ../../) w/ $(srcdir) probably 1/ is the best for minimizing gray hairs long term, although it implies high (but one-time) rework cost. 2/ is best for diagnosing the problem further, as an eventual stepping-stone to 1/. wrt turn-around-time for responses, you can probably expect to find a huge variance even among the same people. e.g., sometimes i don't respond to mail for months or years... thi
Re: Help Requests
Thanks for the response! On Tue, 2003-12-09 at 08:05, Thien-Thi Nguyen wrote: i see from the previous post that you use a manual VPATH methodology. there are two approaches you can try: 1/ undo the unorthodoxy (move auto* files to top-level dir) 2/ prefix relative paths (such as ../../) w/ $(srcdir) I gave #2 a try, and it didn't change the output of make dist. However, moving everything into the top-level dir (#1) did solve the problem. Unfortunately, I don't currently have any control over the directory structure (the motivation behind the attempt is to keep platform specific items, i.e. *nix makefiles, VC++ 6 project files, etc. in subdirectories away from the source files). I'll speak to the powers that be and see about getting this changed. Thanks again. wrt turn-around-time for responses, you can probably expect to find a huge variance even among the same people. e.g., sometimes i don't respond to mail for months or years... Thanks, I'll keep this in mind. Best Regards, Scott signature.asc Description: This is a digitally signed message part
Re: Help Requests
AFAIK There's a third possibility : you could setup a dist-hook target in Makefile.am which allows you to specify completely your dist rule (I had the same problem than yours and used this method). Unfortunately, it also means that you might have to update this rule each time you change metadata in your source tree. /// didier Le mar 09/12/2003 21:19, J. Scott Amort a crit : Thanks for the response! On Tue, 2003-12-09 at 08:05, Thien-Thi Nguyen wrote: i see from the previous post that you use a manual VPATH methodology. there are two approaches you can try: 1/ undo the unorthodoxy (move auto* files to top-level dir) 2/ prefix relative paths (such as ../../) w/ $(srcdir) I gave #2 a try, and it didn't change the output of make dist. However, moving everything into the top-level dir (#1) did solve the problem. Unfortunately, I don't currently have any control over the directory structure (the motivation behind the attempt is to keep platform specific items, i.e. *nix makefiles, VC++ 6 project files, etc. in subdirectories away from the source files). I'll speak to the powers that be and see about getting this changed. Thanks again. wrt turn-around-time for responses, you can probably expect to find a huge variance even among the same people. e.g., sometimes i don't respond to mail for months or years... Thanks, I'll keep this in mind. Best Regards, Scott
Re: Help Requests
... moving everything into the top-level dir (#1) did solve the
problem. Unfortunately, I don't currently have any control over the
directory structure (the motivation behind the attempt is to keep
platform specific items, i.e. *nix makefiles, VC++ 6 project files,
etc. in subdirectories away from the source files).
Drat. I'm in *exactly* the same boat. I can't get 'make dist' to work
with relative paths, and my colleagues will go ballistic if I 'pollute'
the source tree with *NIX config files. I was hoping there was a magic
fix. :-{
AFAIK There's a third possibility : you could setup a dist-hook target
in Makefile.am which allows you to specify completely your dist rule
I suspect I'm too lazy for that. ;-) Seems like it would be more fun to
take a stab at hacking automake to work with my setup. Or is the
config files must be in the top-level dir rule so ingrained into the
tool that this is extremely unlikely?
Re: Help Requests
On Tue, 9 Dec 2003, David Wolfe wrote: AFAIK There's a third possibility : you could setup a dist-hook target in Makefile.am which allows you to specify completely your dist rule I suspect I'm too lazy for that. ;-) Seems like it would be more fun to take a stab at hacking automake to work with my setup. Or is the config files must be in the top-level dir rule so ingrained into the tool that this is extremely unlikely? I don't believe that the config files need to be in the top level directory. You can place those elsewhere since Autoconf Automake can be told where to find the tools. The only claim I have seen is that the top Makefile.am/Makefile.in has to be at the top of the source tree. That only makes for two files in the top directory, for a total of three once the source tree is configured. If you are exceedingly lazy, you might want to look for a new line of work. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Help Requests
Hi All, I posted a request for assistance a few days ago (http://sources.redhat.com/ml/automake/2003-12/msg00042.html), and although I realize this is a rather low volume list, I was hoping someone would have responded by now. Was it an inappropriate post or question? If so, could someone point me to a forum where I could better obtain some assistance with writing a Makefile.am? Thanks for your time. Best Regards, Scott
