Re: [elpa] 01/01: Add requires to fix separate compilation.

Re: [elpa] 01/01: Add requires to fix separate compilation.

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

>     Add requires to fix separate compilation.
> ---
>  latex.el         |    1 +
>  preview.el       |    3 ++-
>  style/acro.el    |    4 +++-
>  style/acronym.el |    4 +++-
>  style/siunitx.el |    2 ++
>  5 files changed, 11 insertions(+), 3 deletions(-)

Thanks, applied.  The change to preview.el was already there (or rather
a similar fix) but in preview.el.in from which preview.el is generated.
So I guess when merging from AUCTeX Git to ELPA, one needs to handle
those generated files manually...

Bye,
Tassilo

Re: [elpa] 01/01: Add requires to fix separate compilation.

[Stefan Monnier]

> Thanks, applied.  The change to preview.el was already there (or rather
> a similar fix) but in preview.el.in from which preview.el is generated.

Oohh... right, I need to pay attention to that.  Thanks for the reminder.

> So I guess when merging from AUCTeX Git to ELPA, one needs to handle
> those generated files manually...

No, it shouldn't be necessary.  The GNUmakefile I added to the elpa.git
code should generate the <foo> from the <foo>.in.


        Stefan

Re: [elpa] 01/01: Add requires to fix separate compilation.

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> So I guess when merging from AUCTeX Git to ELPA, one needs to handle
>> those generated files manually...
>
> No, it shouldn't be necessary.  The GNUmakefile I added to the
> elpa.git code should generate the <foo> from the <foo>.in.

Ah, great.  By the way, today we've applied the patch that pulls all
preview files into the top-level auctex directory.  Would it make sense
to re-initialize the ELPA branch so that auctex git and ELPA are the
very same thing?

From my perspective, I'd be happy to put the files that are usually
generated by the auctex Makefile which can't be built on ELPA under
version control.  I guess for most of them we could make the generation
add a "buffer-read-only: t" file local variable to prevent people from
accidentally editing them or something like that.

Bye,
Tassilo

Re: [elpa] 01/01: Add requires to fix separate compilation.

[Stefan Monnier]

> Would it make sense to re-initialize the ELPA branch so that auctex
> git and ELPA are the very same thing?

No, "re-initialize" is never right because it loses history and might
overwrite and lose changes.  Just use "git merge", as usual.

> From my perspective, I'd be happy to put the files that are usually
> generated by the auctex Makefile which can't be built on ELPA under
> version control.

Reducing the diff between AUCTeX's upstream repository and the branch in
elpa.git is good.  But adding those generated files to AUCTeX's upstream
wouldn't really help elpa.git, I think.

> I guess for most of them we could make the generation add
> a "buffer-read-only: t" file local variable to prevent people from
> accidentally editing them or something like that.

A recent discussion about the way GNU ELPA is organized convinced me
that we should provide some way for packages to be built "by hand"
rather than by elpa.gnu.org's automated script.  That should let us get
rid of those generated files.
This said, I don't know yet how to do that.

In the mean time, making them read-only is probably a good idea.


        Stefan

Re: [elpa] 01/01: Add requires to fix separate compilation.

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Would it make sense to re-initialize the ELPA branch so that auctex
>> git and ELPA are the very same thing?
>
> No, "re-initialize" is never right because it loses history and might
> overwrite and lose changes.  Just use "git merge", as usual.

Well, yes, but in this concrete scenario the ELPA history isn't too
important.  At least not to me if I could get bidirectional "git
merge"-ability otherwise.

Bye,
Tassilo

Re: [elpa] 01/01: Add requires to fix separate compilation.

[Stefan Monnier]

>> No, "re-initialize" is never right because it loses history and might
>> overwrite and lose changes.  Just use "git merge", as usual.
> Well, yes, but in this concrete scenario the ELPA history isn't too
> important.

But overwriting and losing changes is important.
And breaking "git pull" for everyone who follows that branch can be
a problem as well.

> At least not to me if I could get bidirectional "git
> merge"-ability otherwise.

"bidirectional merge" and re-initializing the branch are
largely unrelated.

The one and only thing you need for "bidirectional merge" to work is
that both branches have the same content.  You can get there via "git
merge" just as well.

But currently the two branches are not identical.  Of course, you can
integrate all the elpa.git changes in AUCTeX's upstream which would make
the two branches identical, after which we can merge both ways, but
I suspect you won't quite like this option (e.g. the GNUmakefile I added
to elpa.git means that GNU make ignores the Makefile that should be used
for the "normal" build).

If you want bidirectional merging, I suggest you look at the diff
between the two and see what can be done to resolve those differences.
I tried to make the elpa.git differences "as small as possible" on my
side (tho I did allow myself some liberties), so I expect most of the
changes would need to happen on the auctex.git side, but obviously, some
changes would need to happen on the elpa.git side as well and I'd be
happy to help iron out the differences.


        Stefan

Re: [elpa] 01/01: Add requires to fix separate compilation.

[Stefan Monnier]

>>> So I guess when merging from AUCTeX Git to ELPA, one needs to handle
>>> those generated files manually...
>> No, it shouldn't be necessary.  The GNUmakefile I added to the
>> elpa.git code should generate the <foo> from the <foo>.in.

Actually, I was confused: in elpa.git, there's simply no preview.el.in,
there's only preview.el.
I think the upstream AUCTeX code would benefit from doing the same, FWIW
(the autoconf magic is not really useful here).


        Stefan