|
|
|
Home » U++ TheIDE » U++ TheIDE: Other Features Wishlist and/or Bugs » TheIDE remote package dependencies proposal - dealing with baazar
| TheIDE remote package dependencies proposal - dealing with baazar [message #49906] |
Sun, 03 June 2018 23:02  |
 |
Klugier
Messages: 1099
Registered: September 2012
Location: Poland, Kraków
|
Senior Contributor |
|
|
Hello,
I was thinking how to deal with bazaar problem and I found one interesting solution that we can implement to U++ build infrastructure. However, it will require serve effort to implement.
The main idea of solving that problem is too provide remote package dependency. The user will be able to specif remote dependencies for his package. For example I want to use MessageCtrl from Oblivion in my package without manually copy it to my project...
#include <Remote/Github/Oblivion/MessageCtrl.h> // Should be able to specific GitHub repo directly...
...
#include <Remote/Bazaar/plugin/gtest/gtest.h> // Another example of using self hosted bazzar package...
Before build U++ can check and download required dependencies to Remote assembly folder that can be hidden in ~/.upp/theide directory. After that U++ is super easy to extend and It will be much more powerful with that feature.
This is the concept, so I would be grateful for any comments.
Sincerely,
Klugier
U++ - one framework to rule them all.
|
|
|
|
|
|
| Re: TheIDE remote package dependencies proposal - dealing with baazar [message #49910 is a reply to message #49906] |
Mon, 04 June 2018 09:29  |
Sender Ghost
Messages: 301
Registered: November 2008
|
Senior Member |
|
|
Hello Klugier.
I think, the current U++ build system is flexible on assembly and/or nests level without a need to use specific include(s):
Configuring Packages & Assemblies, Packages, Assemblies & Nests.
Klugier wrote on Sun, 03 June 2018 21:02
#include <Remote/Github/Oblivion/MessageCtrl.h> // Should be able to specific GitHub repo directly...
...
#include <Remote/Bazaar/plugin/gtest/gtest.h> // Another example of using self hosted bazzar package...
If you meant about https://github.com/ismail-yilmaz/upp-components repository, there is some example about how to use MessageCtrl package:
https://github.com/ismail-yilmaz/upp-components/blob/66a389c 08cec65a655b75bc4f7355646f36f708e/Examples/Messages/main.cpp #L1-L2
#include <CtrlLib/CtrlLib.h>
#include <MessageCtrl/MessageCtrl.h>
I may recommend to create upp-components-examples (or with a different name) assembly with following "Package nests", in this case (based on 39bbba5 commit):
path/to/upp-components/Examples;path/to/upp-components/Attic;path/to/upp-components/CtrlLib;path/to/upp-components/Core;path/to/upp/uppsrc
where
path/to/upp-components - is path to cloned https://github.com/ismail-yilmaz/upp-components repository
path/to/upp - is path to root of U++ uppsrc directory (also can be cloned from https://github.com/ultimatepp/mirror repository)
On the other hand, the concept of so-called downloadable/remote/vendor packages may require versioning (or other, e.g. commit) support to solve possible backward compatibility issue(s) or if some specific version is needed. But this may be unrelated.
[Updated on: Mon, 04 June 2018 11:49] Report message to a moderator |
|
|
|
| Re: TheIDE remote package dependencies proposal - dealing with baazar [message #49911 is a reply to message #49906] |
Mon, 04 June 2018 09:59 |
mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
The proposed "remote" looks to resemble some things like artifactory/etc, where the "remote" packages are locally residing in some hidden directory in some cache.
I prefer to build from sources everything, and if I already have source somewhere, I prefer ordinary common location, like "bazaar", not some temporary cache. Also for important projects I keep all required sources (including framework libraries) in the project git, so I can be sure, that I have everything available even 15 years later, if for whatever reason I will need to rebuild the project (and I will have to fight hard only with the obsolete build tools, not also hunting down some old variants of libraries).
This policy is result of my personal experience, how I got burnt over years with my old work, which is now impossible to restore/update.
I guess the "cache" thingy with remote updates makes sense for binary distribution (like jar/aar/war archives in Java and Android world), but even there we often download the packages separately, and put them into project locally (and into git), so again the project git is self-contained, and doesn't need any remote server to be built. It makes the situation somewhat messy when you need to update the third party libraries often (like they are in development), but for most of the time it works reasonably well.
So I believe your proposal goes exactly in opposite direction ("without manually copy it to my project"), and I'm not interested.
But BTW, if you have the packages like in "bazaar" nest, and you have your apps nest configured to use that for build, you don't need to copy the bazaar package to your project nest, it will build from original bazaar location, so the UPP looks to solve this aspect (no need to copy manually) well.
[Updated on: Mon, 04 June 2018 10:00] Report message to a moderator |
|
|
|
|
|
| Re: TheIDE remote package dependencies proposal - dealing with baazar [message #49926 is a reply to message #49914] |
Tue, 05 June 2018 22:20 |
Sender Ghost
Messages: 301
Registered: November 2008
|
Senior Member |
|
|
Hello Radek.
coolman wrote on Tue, 05 June 2018 16:19Do you have any idea how to see only the application package in the IDE package assembly or how to solve this problem better?
I think, that possible to create some nest directory for Rajce package to solve mentioned issue:
1. (Optional) Create some branch:
git checkout -b devel
2. Create Apps (or with a different name) directory:
mkdir Apps
3. Move Rajce to Apps/Rajce directory:
git mv Rajce Apps/Rajce
4. Fix symbolic link for LICENSE file:
ln -sf Apps/Rajce/Copying LICENSE
5. Rename "Rajce/Rajce.upp" to "Apps/Rajce/Rajce.upp" for PROJECT_NAME variable in GenerateCMakeFiles.sh file:
sed -i '' -e '/^PROJECT_NAME=/s|Rajce/|Apps/&|' GenerateCMakeFiles.sh
6.1. Save changes in local repository, if necessary (but also possible to do this for specific steps):
git commit -am "Move Rajce to Apps/Rajce directory"
6.2. (Optional) Merge and delete created branch:
git checkout master
git merge devel
git branch -d devel
7. Fix "Package nests" in some assembly, where Rajce package available:
path/to/Apps;path/to/ultimatepp/uppsrc
where path/to - is path to cloned rajce repository.
For example, separate nest directories also used for upp-components repository.
A possible alternative is to select the required package directly. For example, select ide package for uppsrc assembly:
theide uppsrc ide
[Updated on: Wed, 06 June 2018 00:18] Report message to a moderator |
|
|
|
|
|
| Re: TheIDE remote package dependencies proposal - dealing with baazar [message #49929 is a reply to message #49927] |
Wed, 06 June 2018 08:52 |
Sender Ghost
Messages: 301
Registered: November 2008
|
Senior Member |
|
|
coolman wrote on Wed, 06 June 2018 05:51Hi Mirek,
I'm not him (if you replied to me).
coolman wrote on Wed, 06 June 2018 05:51btw - LAYOUTFILE, TFILE and IMAGEFILE have to be updated as well.
No, this is not needed, if you added Apps (or with a different name) to first path of "Packages nest" for your assembly, where Rajce package available.
Sender Ghost wrote on Tue, 05 June 2018 20:207. Fix "Package nests" in some assembly, where Rajce package available:
path/to/Apps;path/to/ultimatepp/uppsrc
where path/to - is path to cloned rajce repository.
But looks like, you did this because of how current version of upp-cmake script(s) works. Probably, there is a need to add Apps (or with a different name) to include directories of generated CMakeLists.txt file:
# Set the default include directory for the whole project
include_directories ( BEFORE Apps )
In other words, there is may be a need to add ability to specify path(s) for nest(s), which may be used as include directories for compiler also.
[Updated on: Wed, 06 June 2018 09:35] Report message to a moderator |
|
|
|
|
|
| Re: TheIDE remote package dependencies proposal - dealing with baazar [message #49938 is a reply to message #49936] |
Wed, 06 June 2018 10:24 |
Sender Ghost
Messages: 301
Registered: November 2008
|
Senior Member |
|
|
coolman wrote on Wed, 06 June 2018 08:01I apologize for the wrong address.
It's ok, no problem.
coolman wrote on Wed, 06 June 2018 08:01So I need to update upp_cmake to include appropriate path/to/Apps based on the package path using the "include_directories ()".
I may recommend to check how TheIDE uses assembly's nest(s), when "Setup -> Be verbose" selected for build (e.g. it may use them for compiler invocation as -I"path/to/Apps" -I"path/to/ultimatepp/uppsrc", when "Package nests" is "path/to/Apps;path/to/ultimatepp/uppsrc").
[Updated on: Wed, 06 June 2018 12:37] Report message to a moderator |
|
|
|
|
|
Goto Forum:
Current Time: Tue Apr 29 21:01:46 CEST 2025
Total time taken to generate the page: 0.04031 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
