ac-archive-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Macro Packages (was: Archive unification progress)


From: Tom Howard
Subject: Macro Packages (was: Archive unification progress)
Date: Fri, 21 Jan 2005 09:25:38 +1100
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hi Stepan,

> I see two possible solutions:
> 1) Put all three macros in one package, so that if someone patches one of
> them, he will also think about the others.
> 
> 2) Put them to three separate packages.  If AX_INSTALL_FILES is changed you
> have to check all packages which use it...  No, this is not managebale.
> So you probably have to introduce versioning and AX_RPM or AX_DEB_PKG would
> require one particular version of AX_INSTALL_FILES.
> 
> Well, but all this has _nothing_to_do_ with the fact that packages are
> implied as files or not.  You can implement 1) by putting all three macros
> to one file, or 2) by breaking them to individual files.
> 
> If you are concerned about authorship, you can add a comment that this was
> written by Mr. B, and this by Mrs. A.  (The header would say ``written by
> Mr. B and Mrs. A''.)
> 
> So where is the problem?

Option 2 is fine, and pretty much what we have at the moment (except
that there is no package tag :( ) in that each macro is in it's own file.

I can't see option 1 working as so many macros could depend on 1 simple
macro.  As another example, I've just added AX_ADD_AM_MACRO, which
allows you to add custom rules in the Makefiles (eg, `make rpm`, `make
commit`, etc).  Option 1 would mean that all macros that use
AX_ADD_AM_MACRO would need to reside in the one file, which really isn't
feasible.

If we get dependency tracking working, we should be able to
automatically create sudo packages.  The way I see this working from a
users perspective is if they run `make install-ax_rpm`, only ax_rpm and
it's dependencies will be installed.

Additionally macros that aren't meant to be installed by themselves
(e.g. helper macros), could me marked as internal (put` @category
internal` or similar in he m4 file) and no install_X target would be
created for them.  If I can get it to work, this would provide far more
flexibility that a hand placing macros into packages.

What do you think?

Cheers,

-- 
Tom Howard

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x433B299A




reply via email to

[Prev in Thread] Current Thread [Next in Thread]