Re: [Development] Specifying module dependencies
On Monday, June 22, 2015 11:27:33 AM Al-Khanji Louai wrote: > > To the CI system the optional dependencies are > > also required ones. > > So we're not going to test the optionality of said dependencies? That is currently correct. We assume that we have all Qt modules that are dependencies. That's also the way we package. Making smaller builds is possible but not supported. The problem with testing every possible combination of everything is that it quickly becomes exponential in the number of combinations we'd have to test. Frederik > > Louai > > > -Original Message- > > From: development-bounces+louai.al-khanji=theqtcompany.com@qt- > > project.org [mailto:development-bounces+louai.al- > > khanji=theqtcompany@qt-project.org] On Behalf Of Hausmann Simon > > Sent: Wednesday, June 10, 2015 9:48 PM > > To: Thiago Macieira; development@qt-project.org > > Subject: Re: [Development] Specifying module dependencies > > > > Hi, > > > > Why do we need to pin anything beyond the regular git submodules > > handling of qt5.git (where the information is in the tree object)? > > > > In think we should have a configuration file in each module listing > > required and optional dependencies. Qt.pro can interpret that file and > > so can the CI system. To the CI system the optional dependencies are > > also required ones. > > > > Simon > > > > Original Message > > > > From: Thiago Macieira > > Sent: Wednesday, June 10, 2015 18:44 > > To: development@qt-project.org > > Subject: Re: [Development] Specifying module dependencies > > > > On Wednesday 10 June 2015 18:30:34 Frederik Gladhorn wrote: > > > 4) qt5.git > > > in qt.pro we list all modules again, with deps: > > > addModule(qtdeclarative, qtbase, qtsvg qtxmlpatterns) > > > (amusingly this is not even correct, qtsvg is not a dependency of > > > qtdeclarative any more) > > > > That's an optional dependency. > > > > Note that the qt.pro file allows us to do the full build, so unless we > > teach > > qmake to parse any other sources, we'll need to keep it. > > > > That said, I don't think qt.pro should keep SHA-1 of pinned revisions, > > so > > we'll need something else anyway. > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > > > Software Architect - Intel Open Source Technology Center > > > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
> To the CI system the optional dependencies are > also required ones. So we're not going to test the optionality of said dependencies? Louai > -Original Message- > From: development-bounces+louai.al-khanji=theqtcompany.com@qt- > project.org [mailto:development-bounces+louai.al- > khanji=theqtcompany@qt-project.org] On Behalf Of Hausmann Simon > Sent: Wednesday, June 10, 2015 9:48 PM > To: Thiago Macieira; development@qt-project.org > Subject: Re: [Development] Specifying module dependencies > > Hi, > > Why do we need to pin anything beyond the regular git submodules > handling of qt5.git (where the information is in the tree object)? > > In think we should have a configuration file in each module listing > required and optional dependencies. Qt.pro can interpret that file and > so can the CI system. To the CI system the optional dependencies are > also required ones. > > Simon > > Original Message > From: Thiago Macieira > Sent: Wednesday, June 10, 2015 18:44 > To: development@qt-project.org > Subject: Re: [Development] Specifying module dependencies > > > On Wednesday 10 June 2015 18:30:34 Frederik Gladhorn wrote: > > 4) qt5.git > > in qt.pro we list all modules again, with deps: > > addModule(qtdeclarative, qtbase, qtsvg qtxmlpatterns) > > (amusingly this is not even correct, qtsvg is not a dependency of > > qtdeclarative any more) > > That's an optional dependency. > > Note that the qt.pro file allows us to do the full build, so unless we > teach > qmake to parse any other sources, we'll need to keep it. > > That said, I don't think qt.pro should keep SHA-1 of pinned revisions, > so > we'll need something else anyway. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On Mon, Jun 15, 2015 at 08:52:52AM +0200, Simon Hausmann wrote: > We also do have at this point a duplication of repository dependencies > in qt.pro as well as in the repository sync.profile. I do believe that > we can eliminate this dependency without any downside, based on your > idea of placing a .pri file into the top-level directory of each > repository. > that's actually your idea. ;) my idea was parsing the qt.pro file as it exists today. > 2) If you are not part of a Qt release yet but you would still like to > use the continuous integration system, then your code has to build and > work against the dev branch of the modules coming from depending > repositories. > this is quite unreasonable. in fact, our official recommendation is that people should develop against the latest stable branch. at least according to thiago - see also his insistence on making stable the default branch in git. some addons try to stay compatible with older qt releases. for this to really work, they should have two branch configs: the earliest release they are supposed to support, and dev. another thing that speaks for qt5.git as the integration point: up to now, we actually build every module as part of a top-level build, even if we do it only selectively. does the new CI change this approach? so far, it seems that qt5.git is the right place, because it needs to be authoritative for some branches *anyway*. the easiest approach seems to be generalizing the concept and making branching qt5.git easy. up to the point where people don't re-use old feature branches because setting up CI for new ones is such a friggin' PITA, fwiw. with that in mind, please give this another thought: > On Friday, June 12, 2015 09:47:44 AM Oswald Buddenhagen wrote: > > it all boils down to the fact that aggregation must happen top-down. > > we could unify the implementation somewhat by adding more custom fields > > to .gitmodules instead of duplicating some of the information in qt.pro. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On Monday, June 15, 2015 07:40:07 PM Sergio Ahumada wrote: > On 15.06.2015 08:52, Simon Hausmann wrote: > > Perhaps there is a misunderstanding here, so let me confirm also what > > Joerg > > said: At this point we're interested in discussion repository > > dependencies. I understand that are somewhat parallel to the qt module > > dependencies and I also understand that a full build system "evaluation" > > is required to entirely reduce the duplication. However at this point > > we're interested in taking one step into a more modular direction for the > > repositories only. > > > > As it stands today, in order for a repository to be built by the current > > CI > > system, it has to be included in qt5.git. This is an unfortunate artifact > > of the way the system builds but I'm not convinced that it is a > > restriction we want to impose on contributed repositories. Therefore the > > new CI system does not require this. > > maybe I misunderstood .. but are you saying that it is a hard > requirement to be registered in qt5.git in order to able to be part of > the current CI ? > > how did https://codereview.qt-project.org/96072 and > https://codereview.qt-project.org/98297 get merged by the current CI then ? Unfortunately I can't find any build logs for those two modules that support my theory, but from a glance at qtmod_test.pl I have the impression that the following is implemented: 1) Modules inside qt5.git are built using "make module-foo" and thus rely on qt5.pro to have the correct dependency chain. Sync.profile is used to "git reset" to the right "heads" of depending modules. 2) For modules outside qt5.git sync.profile is used to do "make module-bar" and "make module-baz" in qt5.git before building the module itself. If no sync.profile is present, qtbase is the automatic dependency. That means such modules cannot depend on other modules unless they're part of qt5.git. We are eliminating these restrictions - a module can depend on other modules regardless of where they are. All the module needs to be able to do is to build with "qmake" and "make" and support everything necessary with "make install". As it turns out, this is what our existing modules support to a surprising degree :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On 15.06.2015 08:52, Simon Hausmann wrote: > > Perhaps there is a misunderstanding here, so let me confirm also what Joerg > said: At this point we're interested in discussion repository dependencies. I > understand that are somewhat parallel to the qt module dependencies and I > also > understand that a full build system "evaluation" is required to entirely > reduce the duplication. However at this point we're interested in taking one > step into a more modular direction for the repositories only. > > As it stands today, in order for a repository to be built by the current CI > system, it has to be included in qt5.git. This is an unfortunate artifact of > the way the system builds but I'm not convinced that it is a restriction we > want to impose on contributed repositories. Therefore the new CI system does > not require this. maybe I misunderstood .. but are you saying that it is a hard requirement to be registered in qt5.git in order to able to be part of the current CI ? how did https://codereview.qt-project.org/96072 and https://codereview.qt-project.org/98297 get merged by the current CI then ? > I think it would boil down to: > > 1) If you want your Qt module(s) to be part of a Qt release, then your > repository needs to be registered in qt5.git and it will following the Qt > product branching. So your 5.6 branch has to build and work against the 5.6 > branch of all the modules coming from depending repositories. > > 2) If you are not part of a Qt release yet but you would still like to use > the > continuous integration system, then your code has to build and work against > the dev branch of the modules coming from depending repositories. > > Not perfect, no :). But an improvement IMHO. I think we want modules to > become > part of the Qt release and product, and we also want to allowing for > automated > testing as soon as possible. I would say this is mostly how it works today the current CI unless I am really out-of-date :) cheers, -- Sergio Ahumada sahum...@texla.cl ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On Friday, June 12, 2015 09:47:44 AM Oswald Buddenhagen wrote: > On Thu, Jun 11, 2015 at 08:30:37PM +, Gladhorn Frederik wrote: > > On Thursday 11. June 2015 18.47.40 Oswald Buddenhagen wrote: > > > you won't get rid of the redundant dependency specifications anyway, > > > because qt.pro (and the sync.profile's) are about repository deps, > > > while the module's requires() (and whatever other methods they use > > > to exclude themselves) are about module (and non-qt) deps. > > > > > > about sync.profile and pinning, i think you didn't consider > > > non-mainline branches in your plan. you need to specify the branches > > > of the other modules you want to build against *somewhere*. nowadays > > > that could be actually qt5.git's .gitmodules, as it now contains the > > > branches. of course, this implies branching qt5.git for every > > > CI-controlled non-mainline branch. this actually sounds quite > > > logical. i'm all for removing the inter-repo deps from sync.profile > > > - it was never meant to contain them in the first place. > > > > I'm concerned about using qt5.git to hold the information of module > > dependencies since it will never be complete > > this will always be the case at some times as long as the information is > held redundantly. > > > and the information should imho be with the module, not in some other > > git repository. From that point of view sync.profile is preferable. > > > > The reason is that it doesn't scale - when a new module is created, it > > shouldn't have to require registration in qt5.git. This also applies > > to modules that are not (yet) part of official releases or that are > > proprietary for whatever reason. All of these modules don't belong in > > qt5.git. > > new modules can be registered before they enter mainline - there are > plenty of precedents for that. > proprietary modules can be added in a proprietary branch. > > this is really the same discussion as specifying sources belonging to a > project by wildcard. i'm fairly firmly on the 'nope' side on this one > (see discussion in https://bugreports.qt.io/browse/QBS-58). > > > Therefore I would propose containing the information of what > > dependencies a module (on the git repository level) has inside the > > module itself. > > that must include the branches. these will inevitably be redundant with > qt5/.gitmodules. and we've recently seen that this redundancy is > actually causing problems. > > On Fri, Jun 12, 2015 at 09:05:09AM +0200, Joerg Bornemann wrote: > > But it's easily possible to deduce information about repository > > dependencies from module dependencies, isn't it? > > to do that, you need > - a full understanding of the build system. virtually impossible to get > with qmake. > - the repositories themselves, so the build tool can find the modules in > them. this does not help when you need to decide which repositories > you need to clone in the first place. > > it all boils down to the fact that aggregation must happen top-down. > we could unify the implementation somewhat by adding more custom fields > to .gitmodules instead of duplicating some of the information in qt.pro. > but there is no way around the fundamental requirement. even with qbs. Perhaps there is a misunderstanding here, so let me confirm also what Joerg said: At this point we're interested in discussion repository dependencies. I understand that are somewhat parallel to the qt module dependencies and I also understand that a full build system "evaluation" is required to entirely reduce the duplication. However at this point we're interested in taking one step into a more modular direction for the repositories only. As it stands today, in order for a repository to be built by the current CI system, it has to be included in qt5.git. This is an unfortunate artifact of the way the system builds but I'm not convinced that it is a restriction we want to impose on contributed repositories. Therefore the new CI system does not require this. In order for a module to be part of the official Qt release, it also has to be part of qt5.git. I think that part is a reasonable requirement, for the convenience of the users of Qt who would like to build the product in one go. I for one have no intention of trying to change this part. We also do have at this point a duplication of repository dependencies in qt.pro as well as in the repository sync.profile. I do believe that we can eliminate this dependency without any downside, based on your idea of placing a .pri file into the top-level directory of each repository. That can replace sync.profile and qt.pro as well as the CI system can use that file instead of the CI system using sync.profile and the build system using qt.pro. I think such a step would be an improvement that we should pursue. As consequence we could lift the requirement that in order for a module to be built by the CI system it has to be part of qt5.git. I do recognize that it is n
Re: [Development] Specifying module dependencies
On Thu, Jun 11, 2015 at 08:30:37PM +, Gladhorn Frederik wrote: > On Thursday 11. June 2015 18.47.40 Oswald Buddenhagen wrote: > > you won't get rid of the redundant dependency specifications anyway, > > because qt.pro (and the sync.profile's) are about repository deps, > > while the module's requires() (and whatever other methods they use > > to exclude themselves) are about module (and non-qt) deps. > > > > about sync.profile and pinning, i think you didn't consider > > non-mainline branches in your plan. you need to specify the branches > > of the other modules you want to build against *somewhere*. nowadays > > that could be actually qt5.git's .gitmodules, as it now contains the > > branches. of course, this implies branching qt5.git for every > > CI-controlled non-mainline branch. this actually sounds quite > > logical. i'm all for removing the inter-repo deps from sync.profile > > - it was never meant to contain them in the first place. > > I'm concerned about using qt5.git to hold the information of module > dependencies since it will never be complete > this will always be the case at some times as long as the information is held redundantly. > and the information should imho be with the module, not in some other > git repository. From that point of view sync.profile is preferable. > The reason is that it doesn't scale - when a new module is created, it > shouldn't have to require registration in qt5.git. This also applies > to modules that are not (yet) part of official releases or that are > proprietary for whatever reason. All of these modules don't belong in > qt5.git. > new modules can be registered before they enter mainline - there are plenty of precedents for that. proprietary modules can be added in a proprietary branch. this is really the same discussion as specifying sources belonging to a project by wildcard. i'm fairly firmly on the 'nope' side on this one (see discussion in https://bugreports.qt.io/browse/QBS-58). > Therefore I would propose containing the information of what > dependencies a module (on the git repository level) has inside the > module itself. > that must include the branches. these will inevitably be redundant with qt5/.gitmodules. and we've recently seen that this redundancy is actually causing problems. On Fri, Jun 12, 2015 at 09:05:09AM +0200, Joerg Bornemann wrote: > But it's easily possible to deduce information about repository > dependencies from module dependencies, isn't it? > to do that, you need - a full understanding of the build system. virtually impossible to get with qmake. - the repositories themselves, so the build tool can find the modules in them. this does not help when you need to decide which repositories you need to clone in the first place. it all boils down to the fact that aggregation must happen top-down. we could unify the implementation somewhat by adding more custom fields to .gitmodules instead of duplicating some of the information in qt.pro. but there is no way around the fundamental requirement. even with qbs. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On 11-Jun-15 18:47, Oswald Buddenhagen wrote: > you won't get rid of the redundant dependency specifications anyway, > because qt.pro (and the sync.profile's) are about repository deps, while > the module's requires() (and whatever other methods they use to exclude > themselves) are about module (and non-qt) deps. But it's easily possible to deduce information about repository dependencies from module dependencies, isn't it? Cheers, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On Thursday 11. June 2015 18.47.40 Oswald Buddenhagen wrote: > On Thu, Jun 11, 2015 at 03:43:15PM +0200, Simon Hausmann wrote: > > On Thursday, June 11, 2015 12:29:10 PM Oswald Buddenhagen wrote: > > > On Wed, Jun 10, 2015 at 08:32:07PM +, Hausmann Simon wrote: > > > > Hi, > > > > > > > > Ok :) let's try with reduced qmake syntax (just variables, no > > > > functions). > > > > We can still fall back to json if it's too clumsy. > > > > > > as you can "parse anything", what's wrong with parsing the function > > > calls from qt.pro? they match a pretty simple regexp ... > > > > Nothing is wrong with that. In fact that's a great idea :) > > > > So how about we place a dependencies.pri into the top-level directory of > > each module that contains just that one addModule(...) function call? > > > > Then qt.pro can just include whatever is there, the CI can simply parse it > > and - this is different to today's status - the module dependencies are > > tracked within the module instead of in the external qt5.git. > > it's not that easy. > > you won't get rid of the redundant dependency specifications anyway, > because qt.pro (and the sync.profile's) are about repository deps, while > the module's requires() (and whatever other methods they use to exclude > themselves) are about module (and non-qt) deps. > > about sync.profile and pinning, i think you didn't consider non-mainline > branches in your plan. you need to specify the branches of the other > modules you want to build against *somewhere*. nowadays that could be > actually qt5.git's .gitmodules, as it now contains the branches. of > course, this implies branching qt5.git for every CI-controlled > non-mainline branch. this actually sounds quite logical. i'm all for > removing the inter-repo deps from sync.profile - it was never meant to > contain them in the first place. I'm concerned about using qt5.git to hold the information of module dependencies since it will never be complete and the information should imho be with the module, not in some other git repository. From that point of view sync.profile is preferable. The reason is that it doesn't scale - when a new module is created, it shouldn't have to require registration in qt5.git. This also applies to modules that are not (yet) part of official releases or that are proprietary for whatever reason. All of these modules don't belong in qt5.git. Therefore I would propose containing the information of what dependencies a module (on the git repository level) has inside the module itself. I see that the library level dependencies need to be in the build system, that makes sense since it's more fine-grained. Maybe we can still aim to have a recommended way of doing this. Cheers, Frederik > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On Thu, Jun 11, 2015 at 03:43:15PM +0200, Simon Hausmann wrote: > On Thursday, June 11, 2015 12:29:10 PM Oswald Buddenhagen wrote: > > On Wed, Jun 10, 2015 at 08:32:07PM +, Hausmann Simon wrote: > > > Hi, > > > > > > Ok :) let's try with reduced qmake syntax (just variables, no functions). > > > We can still fall back to json if it's too clumsy. > > as you can "parse anything", what's wrong with parsing the function > > calls from qt.pro? they match a pretty simple regexp ... > > Nothing is wrong with that. In fact that's a great idea :) > > So how about we place a dependencies.pri into the top-level directory of each > module that contains just that one addModule(...) function call? > > Then qt.pro can just include whatever is there, the CI can simply parse it > and > - this is different to today's status - the module dependencies are tracked > within the module instead of in the external qt5.git. > it's not that easy. you won't get rid of the redundant dependency specifications anyway, because qt.pro (and the sync.profile's) are about repository deps, while the module's requires() (and whatever other methods they use to exclude themselves) are about module (and non-qt) deps. about sync.profile and pinning, i think you didn't consider non-mainline branches in your plan. you need to specify the branches of the other modules you want to build against *somewhere*. nowadays that could be actually qt5.git's .gitmodules, as it now contains the branches. of course, this implies branching qt5.git for every CI-controlled non-mainline branch. this actually sounds quite logical. i'm all for removing the inter-repo deps from sync.profile - it was never meant to contain them in the first place. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On Thursday, June 11, 2015 12:29:10 PM Oswald Buddenhagen wrote: > On Wed, Jun 10, 2015 at 08:32:07PM +, Hausmann Simon wrote: > > Hi, > > > > Ok :) let's try with reduced qmake syntax (just variables, no functions). > > We can still fall back to json if it's too clumsy. > as you can "parse anything", what's wrong with parsing the function > calls from qt.pro? they match a pretty simple regexp ... Nothing is wrong with that. In fact that's a great idea :) So how about we place a dependencies.pri into the top-level directory of each module that contains just that one addModule(...) function call? Then qt.pro can just include whatever is there, the CI can simply parse it and - this is different to today's status - the module dependencies are tracked within the module instead of in the external qt5.git. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On Wed, Jun 10, 2015 at 08:32:07PM +, Hausmann Simon wrote: > Hi, > > Ok :) let's try with reduced qmake syntax (just variables, no functions). We > can still fall back to json if it's too clumsy. > as you can "parse anything", what's wrong with parsing the function calls from qt.pro? they match a pretty simple regexp ... ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
Hi, Ok :) let's try with reduced qmake syntax (just variables, no functions). We can still fall back to json if it's too clumsy. I certainly prefer qmake syntax from an editing POV because I don't need to quote everything like crazy :) Simon Original Message From: Thiago Macieira Sent: Wednesday, June 10, 2015 22:21 To: development@qt-project.org Subject: Re: [Development] Specifying module dependencies On Wednesday 10 June 2015 19:33:37 Hausmann Simon wrote: > Any particular reason against json, btw? Qmake can read it out of the box, > as opposed to .ini. So the only other option I can think of is a very very > limited qmake subset (variable.subvar = value per line and # comment). Didn't know that, but qmake .pri file is even simpler. http://doc.qt.io/qt-5/qmake-function-reference.html#fromfile-filename-variablename -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On Wednesday 10 June 2015 19:33:37 Hausmann Simon wrote: > Any particular reason against json, btw? Qmake can read it out of the box, > as opposed to .ini. So the only other option I can think of is a very very > limited qmake subset (variable.subvar = value per line and # comment). Didn't know that, but qmake .pri file is even simpler. http://doc.qt.io/qt-5/qmake-function-reference.html#fromfile-filename-variablename -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
Hi, Yeah, we used that when we tried to pin reverse dependencies, something we're not doing anymore. Any particular reason against json, btw? Qmake can read it out of the box, as opposed to .ini. So the only other option I can think of is a very very limited qmake subset (variable.subvar = value per line and # comment). Simon Original Message From: Thiago Macieira Sent: Wednesday, June 10, 2015 21:27 To: development@qt-project.org Subject: Re: [Development] Specifying module dependencies On Wednesday 10 June 2015 18:47:49 Hausmann Simon wrote: > Hi, > > Why do we need to pin anything beyond the regular git submodules handling of > qt5.git (where the information is in the tree object)? We used to. Whether we still need to do that in the new CI, you tell me. > In think we should have a configuration file in each module listing required > and optional dependencies. Qt.pro can interpret that file and so can the CI > system. To the CI system the optional dependencies are also required ones. Fair enough, then it needs to be a simple file format. Not JSON, not PSON, etc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On Wednesday 10 June 2015 18:47:49 Hausmann Simon wrote: > Hi, > > Why do we need to pin anything beyond the regular git submodules handling of > qt5.git (where the information is in the tree object)? We used to. Whether we still need to do that in the new CI, you tell me. > In think we should have a configuration file in each module listing required > and optional dependencies. Qt.pro can interpret that file and so can the CI > system. To the CI system the optional dependencies are also required ones. Fair enough, then it needs to be a simple file format. Not JSON, not PSON, etc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
Hi, Why do we need to pin anything beyond the regular git submodules handling of qt5.git (where the information is in the tree object)? In think we should have a configuration file in each module listing required and optional dependencies. Qt.pro can interpret that file and so can the CI system. To the CI system the optional dependencies are also required ones. Simon Original Message From: Thiago Macieira Sent: Wednesday, June 10, 2015 18:44 To: development@qt-project.org Subject: Re: [Development] Specifying module dependencies On Wednesday 10 June 2015 18:30:34 Frederik Gladhorn wrote: > 4) qt5.git > in qt.pro we list all modules again, with deps: > addModule(qtdeclarative, qtbase, qtsvg qtxmlpatterns) > (amusingly this is not even correct, qtsvg is not a dependency of > qtdeclarative any more) That's an optional dependency. Note that the qt.pro file allows us to do the full build, so unless we teach qmake to parse any other sources, we'll need to keep it. That said, I don't think qt.pro should keep SHA-1 of pinned revisions, so we'll need something else anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Specifying module dependencies
On Wednesday 10 June 2015 18:30:34 Frederik Gladhorn wrote: > 4) qt5.git > in qt.pro we list all modules again, with deps: > addModule(qtdeclarative, qtbase, qtsvg qtxmlpatterns) > (amusingly this is not even correct, qtsvg is not a dependency of > qtdeclarative any more) That's an optional dependency. Note that the qt.pro file allows us to do the full build, so unless we teach qmake to parse any other sources, we'll need to keep it. That said, I don't think qt.pro should keep SHA-1 of pinned revisions, so we'll need something else anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Specifying module dependencies
Hi all,
when talking about how we manage dependencies in the CI system, an interesting
pain point came up during the contributors' summit:
We have several redundant overlapping, not very clear ways of specifying a
module's dependencies. Optional deps make it harder.
I'll list the 5 options I know of below. My question is, can we agree on
something less hidden, with simple syntax that can be used by both qmake and
the CI system.
For the CI system, we can parse pretty much anything, of course we don't want
to implement a qmake copy...
A sensible compromise might be JSON since afaict qmake eats that.
Greetings,
Frederik
What we currently have (probably incomplete):
1) sync.profile
A file in each module that allows specifying dependencies in terms of git
modules (including sha1s), perl syntax. Used by syncqt for public headers but
also has a section like this (qtdeclarative):
# Module dependencies.
# Every module that is required to build this module should have one entry.
# Each of the module version specifiers can take one of the following values:
# - A specific Git revision.
# - any git symbolic ref resolvable from the module's repository (e.g.
"refs/heads/master" to track master branch)
# - an empty string to use the same branch under test (dependencies will
become "refs/heads/master" if we are in the master branch)
#
%dependencies = (
"qtbase" => "",
"qtxmlpatterns" => "",
);
2) qt_modulename_.pro
sometimes things seem to be excluded here, e.g. qtserialport has:
requires(!winrt)
3) module/src/src.pro
example qtwinextras and others:
win32 {
TEMPLATE = subdirs
CONFIG += ordered
SUBDIRS += winextras
qtHaveModule(quick): SUBDIRS += imports
} else {
# fake project for creating the documentation
TEMPLATE = aux
QMAKE_DOCS = $$PWD/winextras/doc/qtwinextras.qdocconf
}
4) qt5.git
in qt.pro we list all modules again, with deps:
addModule(qtdeclarative, qtbase, qtsvg qtxmlpatterns)
(amusingly this is not even correct, qtsvg is not a dependency of
qtdeclarative any more)
5) I don't even understand how qtwebengine does it to not build for
Android/iOS...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
