Jan Pazdziora wrote:
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?
To define dependencies as before.
And they generated?
No.
They (.deps) provide dependencies between views, procs, packages, types, etc that cannot
be generated. The table dependencies could be generated by chameleon using the FK
constraints but that's all. The complexity of the dependencies goes far beyond the tables.
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?
This one is very subjective :)
The only things that blend can do that make cannot (as far as I can tell):
1) Analyse and report on the quality of the .deps files.
2) Replace (@<filename>) references in the upgrade scripts with the content
of the referenced file.
Aside from that, it really has to do with what make *can* do and what make *should* do.
After mucking with the Makefile.schema for a while, I decided to prototype an alternative
and came up with blend.
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.
It's not that simple. Some of the dependencies are more intertwined that this. For
example: the EVR_T has a dependency on the rhn_rpm package. Views depend on tables and
packages which depend of other tables, views and functions. And on, and on.
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.
Yes, good idea.
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.
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
