Re: [CEDET-devel] Migration to bazaar (might be) completed

[Eric M. L. <er...@si...>]

Hi Lluis,

Let me see if I can summarize the strategy from the bits and pieces so far:

1) Match CEDET to Emacs as exactly as possible, pulling in those bits 
that Emacs left behind.

2) Cross-merge between Emacs and CEDET.  Supposedly Emacs will be 
updated to CEDET 1.0, and CEDET will gain any remaining changes 
incompatible with XEmacs or Emacs 22.

3) Devise an updated structure to accommodate an improved development 
model, such as a dir-per-language.  Propose to Emacs and work out 
details.  Implement in CEDET.  Cross-merge up to Emacs.

4) Adapt updated file hierarchy to build to use EDE, obsolete packages 
out of CEDET, design external-to-emacs packaging and install techniques. 
  (possibly using elpa?)

If this is what you are implying, then I think it's a good idea. :)

In this light, I'd like to recommend that 'contrib' be outside of 
'lisp', as those items can't be in Emacs proper, and should be sorted as 
such.

I also think that src (the .wy and .by files) are derived Lisp files the 
way a yacc file has C or C++ in it, and should be near the support .el 
file, ie : c.by + semantic-c.el go together.

Thanks for all  your work on this!

Eric

On 09/01/2010 11:25 AM, Lluís wrote:
> Eric M Ludlam writes:
>
> [...]
>>>> While trying to check in the above, one of the things I noticed is that
>>>> bzr recognizes that semantic/semantic-grammar-wy.el is modified, due to
>>>> the build.
>>>
>>> Aha... apart from files that should be ignored (e.g., .elc), the file you
>>> mention is modified during build. This can be avoided in two ways:
>>> - re-generating parser code only when parser definition is modified (this is a
>>> simple matter of makefile dependencies)
>
>> This is the default, but when you check stuff out the timestamps don't
>> always follow nicely.
>
> I see. It seems to have been reported already, and there is no definitive
> solution to that:
>    https://bugs.launchpad.net/bzr/+bug/245170
>
>
>>> - avoid the modifications inserted by the re-generation step:
>>> - changes in spacing (simply re-commit with new spacing, and no new changes
>>> should arise)
>>> - "History" section is deleted from the .el file; I believe that's because
>>> there's no History section on the file?
>>> - X-RCS field is "resetted"; I've deleted all those fields from my local
>>> branch, as I think they're no longer necessary
>>> - "Author" and "Created" fields are set during build, but I think they should
>>> be maintained from the parser definition
>
>> These seem like good ideas.  CVS somehow knew that nothing was changing,
>> whereas bazaar detects many changes.  Does bazaar strip whitespace in
>> some fancy way?
>
> Not that I'm aware of. Is it possible that the current generator code is
> producing files with different spacing?
>
>
>>> Now, if you look into the results after a "make clean-all", you'll see that,
>>> additionally, "semantic/bovine/semantic-skeleton-by.el" is deleted, but was also
>>> present on the repository. I think the compiled skeleton parser should not be
>>> present on the repository, or else not deleted during a clean action.
>
>> This I do not recall.  It doesn't seem like it is necessary to me.
>
> Well, I thought the compiled skeleton was there just let others quickly see how
> a compiled parser looks like. But if you don't see a reason for it to be there,
> I'll simply delete it.
>
>
>>> This brings me to the point that on my local branch, I cannot seem to regenerate
>>> the Makefile files from their Project.ede definitions. Right now I'm rewriting
>>> the make infrastructure to work with plain Makfiles, as right now I'm heavily
>>> reorganizing the location of files.
>
>> The old Project.ede files are not going to work in this new world.  A
>> new project, likely for all of CEDET should probably be built, and the
>> old Project files abandoned.
>
>> Basically, delete all the old Project.ede files, and issue the command
>> "M-x ede-new" under CEDET to create a Makefile project.  Then the same
>> for every subdir, and add targets and files to targets as you go.
>
>> It has always been useful using EDE to manage CEDET to make sure that it
>> is always well tested. :)
>
> Aaahhh... now it makes sense :)
>
> Well, I'll start with makefiles from scratch, which I'm more comfortable with
> right now, and a rewriting with EDE will follow once CEDET matches the interface
> in current emacs (all the simple global-enabling functions and the like).
>
> This reminds me of something else. There are a few lisp files on the root
> directory, are all of them still alive? I'm specially talking about
> cedet-build.el, as then I should rewrite it to follow the new directory
> structure.
>
>
>>> The layout I want to have at the end is:
>>>
>>> cedet
>>> |-<various top-level files>
>>> |- src    -- bovine/wisent parser definitions (maybe it should be called parsers)
>
>> By this you mean the .by and .wy files?
>
> Yes. In part because emacs is only shipping the compiled parsers, not the
> sources/definitions.
>
>
>> There was a request via the email list to group code for a particular
>> mode together.  Perhaps like:
>
>>     |- modes
>>     |   |- c (home of c.by, semantic-c.el, semanticdb-cscope.el)
>>     |   |- java (home of java.wy, java-tags.wy, ...)
>
>> Of course, then does SRecode templates for C or Java go in those dirs
>> too?  I would guess this would be the way to get everything
>> "intergrated" together more tightly, helping identify code for a
>> particular language all in one place.
>
> Right, this should ease language-specific development, but some pieces are
> shared among different languages (e.g., cscope support mutiple languages).
>
>
>> This would probably need to be run by the Emacs maintainers, since we
>> are also trying to get the two trees to match.
>
> Well, first I'll try with the current reorganization, which is still big enough
> to take some time :)
>
> We can talk with the emacs people about this after the next cross-merge.
>
>
> [...]
>>> |   `- speedbar -- is speedbar going to be developed by CEDET, or has it moved
>>> |               -- altogether to emacs? the code in emacs is not exactly the
>>> |               -- same as the one in cedet, but haven't really checked on the
>>> |               -- differences
>
>> Speedbar in CEDET is different only in that I've kept in code that
>> allows it to run in ancient versions of Emacs.  I have not needed to
>> enhance Speedbar in a very long time.
>
> Well, my question is if it makes sense to maintain it inside cedet, just like
> eieio. If not, I'll simply delete the directory, but if it makes sense, it
> should be synched with the emacs version.
>
>
> [...]
>>> `- tests  -- all test suites, organized per-package/subsystem
>>> -- (e.g., language parsing/completion, ede, ...)
>
>> There are two batches of tests.  Unit tests (close to the source) and
>> integration tests (the cit-* stuff) which tests the packages from a
>> pretty high level.  There are many tests in the same file as the sources
>> it tests.  Those may be a challenge for you to find. ;)
>
> Like the 'modes' directory, I'll leave this for now.
>
>
> Lluis