On Tue, May 12, 2009 at 12:42:32PM -0400, Jeff Ortel wrote:
>
> MAKEFILES
>
> The Makefile.schema refactored into a /regular/ makefile. Dependency sorting
> and .sql
> file aggregation split out into a build tool named "blend". Although, make
> does do
> dependency sorting with the .deps files, the Makefile.schema (although, a
> clever
> application of the technology) seems to exceed make's intended use and was
> difficult to
> maintain and debug. Blend also provides analysis of .deps files and reports
> unused
> rules, unfound references, duplicate files and circular dependencies.
> Anyway, if someone
> really believes we should go back to using make for this, I suppose we can.
I'm confused. What does blend really do and how does it fit into the
build chain? There still seem to be files like
./oracle/views/views.deps
./oracle/tables/tables.deps
./oracle/packages/packages.deps
What are they for? And they generated? If they are, why do we have
them in our sources in the first place? If they are not geenrated,
what does blend really do what make could not?
I wonder if we should (again, independently from the PostgreSQL
port effort) focus on making the dependency resolution more
automatic, rather than rewrite working thing with another thing.
The types can be collated mostly automatically -- tables before
triggers, types before tables, functions before triggers but after
tables, etc. For the procedural code, we can recompile the whole
schema anyway.
For tables, we could generate the the graph / Makefile just by
grepping the source code. For other types, I wonder if we could put
the dependency information to the start of the SQL file, something
like
-- Copyright (c) 2008 Red Hat, Inc.
--
-- This software is licensed to you under the GNU General Public
License,
--
[...]
-- Requires: procs/lookup_cf_state
create or replace function
lookup_first_matching_cf (
[...]
By having the dependency spelled out in the source code where the
object is defined rather than in some separate long file, we would
make it easier to maintain and keep up-to-date.
I'd consider this a higher priority than any decision about make
replacement. Maybe, when we do something about the dependencies in
general, we will find out that any issues you might have hit with
make are either gone or much more manageable.
--
Jan Pazdziora
Senior Software Engineer, Satellite Engineering, Red Hat
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
