[Top][All Lists]
[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
- Re: Archive unification progress, (continued)
- Re: Archive unification progress, Tom Howard, 2005/01/16
- Re: Archive unification progress, Peter Simons, 2005/01/17
- Re: Archive unification progress, Tom Howard, 2005/01/17
- Re: Archive unification progress, Peter Simons, 2005/01/18
- Re: Archive unification progress, Stepan Kasal, 2005/01/18
- packages (was: Archive unification progress), Peter Simons, 2005/01/18
- Re: Archive unification progress, Tom Howard, 2005/01/18
- Re: Archive unification progress, Stepan Kasal, 2005/01/20
- Macro Packages (was: Archive unification progress),
Tom Howard <=
- Re: Macro Packages (was: Archive unification progress), Stepan Kasal, 2005/01/21