At 08:04 PM 8/27/2001 -0400, you wrote:
>
>
>> This is a beautiful thing...
>>
And only recently possible with one package. See below.
>> Signaling: (error "ECB requires a semantic-version >= 1.40beta7!")
>> signal(error ("ECB requires a semantic-version >= 1.40beta7!"))
>> [SNIP]
>>
>> I just grabbed the latest ECB to check it out - did a quick setup and
>hadn't
>> looked at prereq's yet.
>>
>> I think this type of startup checking would help JDE support as well...as
>in
>> reduce the maillist traffic a decent amount for this frequent basic setup
>> problem.
>
>
>Yes this is exactly the kind of checking I am shooting for in a one shot
>installer.
>
>
>
>I have had some time to spend on building a combined installer, and I have
>the skeleton
>of a one-shot installer for the 5 elisp packages. I also have several
>questions:
>
>
>
>________________
>(#1) My toughest problem
>
>I am shooting for an elisp only installer. This has the huge advantage of
>having a single
>combo package that works across different OSs and across different Emacs'
>as well.
>This means that I cannot use the 'Makefiles' included several of the
>packages.
>
>I have extracted the JDE elisp compile-if-needed functions and adapted them
>for use with other
>directories. This seems to work for some of the packages, but it fails on
>the speedbar
>package. I think it is failing because it is trying to compile an optional
>lisp file
>called w3-sb.el which requires w3-imenu (if memory serves).
Check if w3 is loadable, if not, skip compilation of w3-sb.el.
>I cant run this Makefile, so I am trying to look at the source to
>understand what it is shooting
>for. It looks like this approach is close to working, but I may need to
>include
>some of the logic in these makefiles in the elisp compiler.
>
>Any ideas on this?
>
>An alternative would be to include the .elc files in the distribution. I
>know in theory
>the .elc files from Xemacs and Gnu emacs are not byte compatible. In
>practice are they?
>Even if they are, is this a bad idea?
>
Yes.
>
>________________
>(#2) Is there a robust way to check OS version within emacs under all
>OSes, or
> am I dreaming.
>
>Paul responded to this earlier with:
>> Please look at the JDE code. There are dozens of examples of OS checking.
>> - Paul
>
>I did look in the JDE code, and found many instances of testing the _type_
>of OS
>in use (e.g. 'system-type'). I could not find any checks of the OS
>_version_.
>
I don't know of anyway to do this. Why not ask the user?
>My ultimate goal is to have a JDE that either works, or tells you why it
>cannot work,
>with your environment (e.g. Must have Win2000 Service pack 2). Of course I
>will not
>achieve this, but even 80% would be better than nothing.
>
>
>
>_______________
>(#3) What are the earliest versions of the five JDE related packages that
>will work
>with the current system?
The release notes for JDE 2.2.8 tell you that.
>
>Should I flag an error if anything except the most recent version is
>present in the enviroment?
No.
>Or is there a set of minimum versions that someone can supply me with.
>
>Can I assume that future versions of the same packages will retain backward
>compatibility, or
No. They sometimes don't.
>should I flag those to the user?
>
Only if the user's version is incompatible.
>Finally, it seems that earlier versions of some of those packages (which
>are part of the Xemacs
>current distribution) do not have any version variables present.
Ergo the reason the JDE has not done this before now.
> I am
>assuming that any package
>w/o version variables are incompatible. correct assumption?
>
No.
>
>
>_________________
>(#4) Ok I can implement this one from scratch, but I am wondering if it
>is already
>out there (or in emacs already). I want to execute the command "java
>-version" as a
>command line command and get back the output as a string. "start-process"
>almost
>works, but it doesn't handle the forward/backward slash issue (I think I
>saw some JDE
>code for that)
grep for directory-sep-char
> and it doesn't tell me when the command has terminated.
Use set-process-filter and accept-process-output. There are numerous
instances of the usage of these functions in the JDE code.
>
>Is there a command that wraps all this up for me?
>
No.
- Paul
