[MCOL-1259] ColumnStore Data-Adapters needs a top level cmake for building all Data-Adapters Created: 2018-03-12  Updated: 2023-10-26  Resolved: 2018-06-04

Status: Closed
Project: MariaDB ColumnStore
Component/s: ?
Affects Version/s: 1.1.4
Fix Version/s: 1.1.5

Type: New Feature Priority: Major
Reporter: David Hill (Inactive) Assignee: Ben Thompson (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Sprint: 2018-10, 2018-11

 Description   

Currently each ColumnStore Data Adapters is built separately on the build machines and buildbot. So any time a new adapter is added, the build scripts have to be updated. Need a top level cmake file that will build all data-adapters at once to simply the build process.



 Comments   
Comment by Jens Röwekamp (Inactive) [ 2018-05-09 ]

from the kettle / pdi adatper site there is no problem with this.

Comment by Jens Röwekamp (Inactive) [ 2018-05-18 ]
  • top level cmake for data adapters introduced
  • changed all CMakeList.txt files accordingly, and included tests via make test where possible
  • changed maxscale cdc docker test installer to use new maxscale-cdc-connector rpm dependency packages

For testing:

  • please test each data adapter manually for functionality after make install and also their package installation after make package.
  • For kettle / PDI the test suite introduced in MCOL-1401 could be used.
  • Please consult markus makela on how to test the other 3 connectors.
Comment by David Thompson (Inactive) [ 2018-05-18 ]

Hi Ben, you are much more knowledgable on cmake than me so can you review this. Right now the directory level cmakes fail with this change so the buildbot check fails correctly not sure if you have any ideas on fixing this as i think this ought to work?

Regardless we'll need to change buildbot to use the top level cmake / make after this gets checked in. Also this should be merged up to develop as well for buildbot too.

Comment by Ben Thompson (Inactive) [ 2018-06-04 ]

Changes have been merged and works for buildbot

Generated at Thu Feb 08 02:27:24 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.