You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Martin Kraemer <Ma...@mch.sni.de> on 1997/09/19 13:45:37 UTC
Shortcomings in Makefiles
I'm going to be on vacation over the next week, and will be back on Oct
3rd only. If there are enough apache core members left (who are _not_
currently on vacation) and you intend to publish the 1.3b1 version until
then, here's a wish list of (solved by Paul?? but yet not checked-in)
topics about the Makefile generation.
* modules.c is being compiled before the descent into the appropriate
os/{unix,...} directory. The compilation therefore fails on a freshly
unpacked apache source tree, since at that moment os*.[ch] are still
missing from the include path. This could either be solved by
additional -Ios/{unix,...} include statements, or better by visiting
the os/{unix,...} directory first so that it will initialize
main/os*.[ch]
* os/{unix,...}/Makefile still copies os*.[ch] to main/, instead of
setting symlinks.
Pseudo-Patch:
all: $(LIB)
- cp os.h ../../main
- cp os-inline.c ../../main
+ @rm -f ../../main/os.h ../../main/os-inline.c
+ @ln -s ../os/unix/os.h ../os/unix/os-inline.c ../../main || \
+ { echo "Could not create SymLinks - using HardLinks instead; ln os.h os-inline.c ../../main; }
* The module depencencies could/should be checked; possibly, a
dependency of more include files would be useful. Currently, only
mod_speling depends on os.h
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: Shortcomings in Makefiles
Posted by Paul Sutton <pc...@hyperreal.org>.
On Fri, 19 Sep 1997, Martin Kraemer wrote:
> * In os/{unix,...}/, the rule to re-create ../../main/os*.[ch] is
> executed last, after compiling os.c -- shouldn't it better be
> executed as the very first thing?
Does it make any difference?
//pcs
Re: Shortcomings in Makefiles
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Fri, Sep 19, 1997 at 02:45:37PM +0200, Martin Kraemer wrote:
> * modules.c is being compiled before the descent into the appropriate
> os/{unix,...} directory.
* In os/{unix,...}/, the rule to re-create ../../main/os*.[ch] is
executed last, after compiling os.c -- shouldn't it better be
executed as the very first thing?
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: Shortcomings in Makefiles
Posted by Dean Gaudet <dg...@arctic.org>.
This won't work with make -j ... but I'm OK with it.
make -j is kind of annoying to support in some cases.
Dean
On Mon, 22 Sep 1997, Paul Sutton wrote:
> On Fri, 19 Sep 1997, Martin Kraemer wrote:
> > * modules.c is being compiled before the descent into the appropriate
> > os/{unix,...} directory. The compilation therefore fails on a freshly
> > unpacked apache source tree, since at that moment os*.[ch] are still
> > missing from the include path. This could either be solved by
> > additional -Ios/{unix,...} include statements, or better by visiting
> > the os/{unix,...} directory first so that it will initialize
> > main/os*.[ch]
>
> Yeah, good point. Here is a simple patch to build modules.o last
>
> Index: Makefile.tmpl
> ===================================================================
> RCS file: /export/home/cvs/apachen/src/Makefile.tmpl,v
> retrieving revision 1.65
> diff -u -r1.65 Makefile.tmpl
> --- Makefile.tmpl 1997/09/12 13:35:27 1.65
> +++ Makefile.tmpl 1997/09/22 18:08:02
> @@ -26,7 +26,7 @@
> @echo "If not, you will at least have to touch @@Configuration@@."
> @false
>
> -httpd: modules.o subdirs
> +httpd: subdirs modules.o
> rm -f buildmark.c
> echo 'const char SERVER_BUILT[] = "'`date`'";' > buildmark.c
> $(CC) -c $(CFLAGS) buildmark.c
>
> > * os/{unix,...}/Makefile still copies os*.[ch] to main/, instead of
> > setting symlinks.
>
> I've already posted a patch to do this. I don't think we need to worry
> about falling back to hard links though, since every variant of the
> os/unix platform supports symbolic links. The only platforms which do
> not support symlinks are OS/2 and Win32, and they both use different
> os/* directories.
>
> > * The module depencencies could/should be checked; possibly, a
> > dependency of more include files would be useful. Currently, only
> > mod_speling depends on os.h
>
> Um, yeah.
>
> //pcs
>
>
Re: Shortcomings in Makefiles
Posted by Paul Sutton <pc...@hyperreal.org>.
On Fri, 19 Sep 1997, Martin Kraemer wrote:
> * modules.c is being compiled before the descent into the appropriate
> os/{unix,...} directory. The compilation therefore fails on a freshly
> unpacked apache source tree, since at that moment os*.[ch] are still
> missing from the include path. This could either be solved by
> additional -Ios/{unix,...} include statements, or better by visiting
> the os/{unix,...} directory first so that it will initialize
> main/os*.[ch]
Yeah, good point. Here is a simple patch to build modules.o last
Index: Makefile.tmpl
===================================================================
RCS file: /export/home/cvs/apachen/src/Makefile.tmpl,v
retrieving revision 1.65
diff -u -r1.65 Makefile.tmpl
--- Makefile.tmpl 1997/09/12 13:35:27 1.65
+++ Makefile.tmpl 1997/09/22 18:08:02
@@ -26,7 +26,7 @@
@echo "If not, you will at least have to touch @@Configuration@@."
@false
-httpd: modules.o subdirs
+httpd: subdirs modules.o
rm -f buildmark.c
echo 'const char SERVER_BUILT[] = "'`date`'";' > buildmark.c
$(CC) -c $(CFLAGS) buildmark.c
> * os/{unix,...}/Makefile still copies os*.[ch] to main/, instead of
> setting symlinks.
I've already posted a patch to do this. I don't think we need to worry
about falling back to hard links though, since every variant of the
os/unix platform supports symbolic links. The only platforms which do
not support symlinks are OS/2 and Win32, and they both use different
os/* directories.
> * The module depencencies could/should be checked; possibly, a
> dependency of more include files would be useful. Currently, only
> mod_speling depends on os.h
Um, yeah.
//pcs