Comments (5)
My plan is to go even further: I will create one Git repository per library (containing the code, its examples, its tests and its doc). People who want to use regular expressions don't necessarily need to get the XML library.
My objective is to finish migrating to void-safety (only half of the xslt part of the XML library remains to be done), and then split the Gobo repository into smaller ones.
It's feasible. But I will need to use all my Git skills in order to pull the history of each library in its new repository (knowing that the code will come from various folders: library/examples/...).
from gobo.
Please don't - there is absolutely no problem on any modern system to
have a few classes or binaries lying around you don't use.
But keeping everything versioned and consistent is a nightmare.
I would strongly vote for keeping GOBO as a single GIT repository.
Bernd
On 15/08/15 08:32, Eric Bezault wrote:
My plan is to go even further: I will create one Git repository per
library (containing the code, its examples, its tests and its doc).
People who want to use regular expressions don't necessarily need to
get the XML library.
My objective is to finish migrating to void-safety (only half of the
xslt part of the XML library remains to be done), and then split the
Gobo repository into smaller ones.
It's feasible. But I will need to use all my Git skills in order to
pull the history of each library in its new repository (knowing that
the code will come from various folders: library/examples/...).—
Reply to this email directly or view it on GitHub
#8 (comment).
from gobo.
I'm not convinced by your argument that keeping all classes in the same project because this is not a problem to keep classes or binaries lying around.
In my point of view, splitting gobo in two parts will improve maintainability process on some points :
- Improve clusters visibility (e.g some classes in "library/tools" cluster are really specific to Gobo tools, no interest to keep them in the "main" Gobo library);
- Simplify project structure & documentation.
Moreover, these changes have no functional impact
from gobo.
I'm also for the split.
@pgcrism did the same for the SAFE Project when it was moved from Sourceforge to Github.
I don't remember if the history was kept: maybe we should just ask him...
from gobo.
There are several reasons I want to split the Gobo repository into several repositories, one per library.
The first one is that there are some libraries in there which have been contributed by people who either lost interest in Eiffel or just don't want to maintain their libraries anymore. So I agree that having a single repository helps keeping compatibility. But guess who has to do the job? My hope is that it will be easier for people who are too shy to contribute to the whole Gobo project to make the first step and contribute to a smaller project.
Also, many times in the past I heard about people not willing to use some part of the Gobo libraries just because they didn't need everything. For example they didn't want to use the regexp classes because they did not need the XML classes. I can understand that people might want to get everything, but some don't. Having one repository per library allows people to get just what they want, and still have a whole Gobo package which includes everything (from the different repos, using submodules for example) for the others.
Typically, people are not looking for the Gobo package. They are looking for a library which will help them in their work. For that, there are some pages on the Web listing available Eiffel libraries per functionalities. Because Gobo contains many libraries, it is often not listed in the right places in these lists. I hope that having one repo per library will make things clearer as to what libraries are available. In particular if we want the Github EiffelHub account to regroup all available Eiffel libraries (through forks), or if some Eiffel libraries distributions (using iron or not) want to organize libraries per functionalities (there has been some discussions about that on ISE's mailing list in the past), things shold be easier that way.
And it's not just about Gobo. During the past few years my wish has been that ISE's libraries (such as EiffelVision) be in repositories independent of EiffelStudio. As mentioned above, it would make it easier to create packages including Eiffel libraries independently of any Eiffel compiler or other Eiffel library writers. For example I want to be able to use EiffelVision with the Gobo compiler without having to download the whole EiffelStudio package.
from gobo.
Related Issues (20)
- Use _stat instead of _stat64i32
- I'm trying to use an unsupported compiler HOT 2
- Another unsupported compiler HOT 4
- Develop without Eiffel Studio?
- How to have/write system.ecf? HOT 2
- Documentation sucks
- PECF support
- Q: how to print eiffel object size in bytes HOT 2
- Q: is it a real flaw in the Eiffel's renaming mechanism in this diamond problem? HOT 5
- How to set the make jobs used by `geant`? HOT 1
- Upgrade www.gobosoft.com to use https
- Gobo XPath library
- Q: how to find all the renamed attributes of a (AST processed) class in the gec compiler ? HOT 70
- gec compiler bug: type '[detachable] STRING_8' of actual argument #1 does not conform to type '[attached] UC_STRING' of formal argument in feature `is_equal' in class '[detachable] UC_STRING' HOT 3
- is it possible to support: **** language not recognized: C Macro use <ev_gtk.h> HOT 56
- /Eiffel_23.09/library/cURL/spec/include/eiffel_curl.h:18:10: fatal error: eif_eiffel.h: No such file or directory HOT 6
- Q: is there a way to print an object's memory address in Eiffel? HOT 7
- build failure: undeclared function 'T238f30e1' HOT 2
- change `HASH_TABLE` to `DS_HASH_TABLE`, the `gec` build program (via `make gobo`) will segfault HOT 5
- Installation problem HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gobo.