×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Read More...

indilib github migration

  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indilib github migration

Yes the externals is a bit of a problem.
Actually more so then the partial clone issue.
The repo is not so large by today's standards - my clone takes just 150MB.
So I would not loose any sleep over this issue. The structure of the tree
is harder - but in my opinion should be re-organized anyway.
Building indi and its drivers is not trivial for a novice and is a bit confusing.
So maybe we should use this opportunity for reorganization?
7 years 11 months ago #8253

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic indilib github migration

Well, I'm open to suggestions. The fact is all drivers need the common cmake_modules directory. I don't think a symlink will do it. Also, no need to migrate branches and tags, just trunk is enough.
7 years 11 months ago #8255

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 10

Replied by NickK on topic indilib github migration

As a new "builder" for the first time over the weekend, I had to hunt a little but the main issue is the kf5 dependency. It's probably better to say install KDE Framework 5 (the entire lot to make sure).

Note that I'm an amateur in development (BSc + 18 years) and many of the new recruits (Per for example) are very experienced too.

The build seemed relatively painless, although adding new drivers etc will be a different kettle of fish. I'd like to simply add a directory with a local cmake perhaps and the system then finds during the build. Focusing on restructuring to make it easy create new drivers and maintain existing - especially as I see INDI becoming more of a defacto cross platform system.
ODROID C2 Ubuntu
Last edit: 7 years 11 months ago by NickK.
7 years 11 months ago #8256

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indilib github migration

That is good - I have succeed in importing the whole tree (with tags and branches) but it resulted in the huge mess. i.e. the tree had a lot of branches of historical meaning and some probably even not much so (experiments/tests etc.).
Here is a list of branches
  0.6                 9d33e71 Reflect changes in 0.6
  0.9                 b730ae7 Create the libindi 0.9 branch
  0.9@184             3550cdf Build updates
  0.9@599             b4d2cd4 Updated changelog
  cmake-restructure   ee03737 Sync to trunk
  libindi-0.9.7       ef97a50 Branching 0.9.7
  libindi-0.9.7@1110  60552eb remove filter properties on disconnect
  libindi-0.9.7@184   3550cdf Build updates
  libindi-0.9.8       08e6e81 Creating 0.9.8 branch
  libindi-0.9.8@1500  0cda882 Reintegrated branches/libindi-align
  libindi-0.9.8@184   3550cdf Build updates
  libindi-align       479c9f6 Copy some missing files
  libindi-align@1088  cb4a49e Looks like final changelog for 0.9.7
  libindi-align@184   3550cdf Build updates
  libindi-guider      ac65c36 signature of StartExposure and StartGuideExposure is changed to bool, auto loop feature is working with rapid guide enabled
  libindi-guider@1105 cb4a49e Looks like final changelog for 0.9.7
  libindi-guider@184  3550cdf Build updates
  libindi-win         2a9c9c3 synced with trunk at 917 (merge only, untested)
  libindi-win@184     3550cdf Build updates
  libindi-win@794     771b344 update svn externals
* master              bee3049 GPSD: Merge astroberry gps driver with upstream gpsd driver.
  work                1d08b98 Update to latest INDI API

So you are saying we can do with just trunk and we will use svn for historical stuff ?

That will make it much easier and manageable.

As for the externals - if it is only cmake directory maybe we can just split it off into separate repo
and use git submodules to insert it it proper places? Would that be all right? It is not difficult git-wise
We just split the repo post-import and remove duplicating parts from the main repo and cmake repo.
This is a fairly well known procedure.
7 years 11 months ago #8257

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic indilib github migration

Yup, just trunk is sufficient. SourceForge subversion will remain RO. And I think "submodules" is the way to go after reading about the subject a bit, but I'm not sure how to proceed with this myself. As long as if I clone, for example, 3rdparty/indi-eqmod, then cmake_modules is automatically checkout out along.
7 years 11 months ago #8258

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indilib github migration

That is a good point (multi platform support) - git submodules work on all platforms I suppose - symbolic links not so much.
Thanks to Jasem's efforts the build docs are much better now. I remember scratching my head quite a bit when I was starting my development of the new driver, and I still think the system is "slightly convoluted".
7 years 11 months ago #8259

Please Log in or Create an account to join the conversation.

  • Posts: 27
  • Thank you received: 32

Replied by Marco Gulino on topic indilib github migration

knro: yeah, submodules are the way, but remember: you're not allowed to clone 3rdparty/indi-eqmod, unless it's a standalone git repository.
You have to clone all 3rdparty each time.
As I said, probably the cleanest way to do it is to have three projects: core, 3rdparty, and cmake_modules
Last edit: 7 years 11 months ago by Marco Gulino.
7 years 11 months ago #8260

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indilib github migration

That is exactly how it works (I mean submodules got planted in proper places during clone).
My suggestion is as folows:
- You make a big announcement about migration and ask people (active developers) to get an account on github and fill in missing data authors.txt posted at project repo (thanks BTW for filling in some data there).
- I will try to make a test import of just trunk. We check if all is properly imported and if all users are properly mapped
- We collect/correct missing author info
- We make a final import and switch the svn to RO
I can make a commitment to do the imports etc at 27-29 May. How is that working for you Jasem?
Regarding the structure. I was thinking about splitting the project into three parts: core library and drivers, cmake, third party drivers, maybe packaging
Maybe the core could be further split into library and server&core_drivers - but I am not so sure there is any point doing this.
Alternatively we can use even finer grain splitting - like you have used on launchpad but this will make it more difficult for new developers to start their own drivers. It is easy to clone a repo add your driver and send a pull request. There is no similar mechanism (I know of) to propose to include your own repo into a organizational project like libindi is.

What do you think?
The following user(s) said Thank You: Jasem Mutlaq, Derek
7 years 11 months ago #8261

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic indilib github migration

Great, I'll get to it and ask the current developers to register github accounts if not done already. It seems the organizational structure is similar to what we have:

1. cmake
2. libindi
3. 3rdparty
4. packaging
5. macosx? I'll ask Peter, maybe we can keep this in subversion

No need to further split libindi. 27-29 is perfect, hopefully we can get most of the developer's info by then.
7 years 11 months ago #8262

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indilib github migration

Ok. I like this scheme. Remember to ask them to fill in the data for authors.txt
7 years 11 months ago #8263

Please Log in or Create an account to join the conversation.

  • Posts: 200
  • Thank you received: 57

Replied by Paweł on topic indilib github migration

All Authors!
I have done a test import of indilib from svn.

github.com/indilib/test-import

Please do not use it for anything except testing what worked and what did not.
Please report any issues. Particularly check if your contributions are properly mapped to your github accounts.
If not either report it to me or correct authors.txt file posted in (github.com/indilib/experimental-import)
Please do it now - we will not be able to correct it after final import.
The following user(s) said Thank You: Derek
7 years 11 months ago #8268

Please Log in or Create an account to join the conversation.

  • Posts: 983
  • Thank you received: 375

Replied by Radek Kaczorek on topic indilib github migration


This structure makes things much easier and transparent. We will avoid cases of desynced cmake_modules which are now hard copied to new drivers and need to be manually resynced in case of major changes to indilib.
7 years 11 months ago #8277

Please Log in or Create an account to join the conversation.

Time to create page: 0.597 seconds