Posts: 245
Threads: 48
Joined: Jun 2015
Reputation:
4
09-01-2015, 04:23 PM
(This post was last modified: 09-01-2015, 05:01 PM by bbjimmy.)
There is need for only one libyab.so on the system. libyab.so IS backward compatible.
If one has a program compiled with yab1.7.5 and later installs yab 1.7.6, the program made with 1.7.5 will still run properly even though libyab,so was replaced and updated with the later yab version.
The problem with a libyab hpkg is that currently there is no versioning of libyab.so, and simply requiring libyab.so may break things. Requiring yab >= 1.xx solves the breakage. If I make a libyab .hpkg, it will have versioning that matches the yab version making it necessary to specify the libyab version, libyab.so >= 1.xx, just like one now needs to do with yab.
Again, lots of work for little benefit.
Posts: 54
Threads: 7
Joined: Jun 2015
Reputation:
2
09-01-2015, 10:30 PM
(This post was last modified: 09-02-2015, 12:04 AM by lelldorin.)
(09-01-2015, 04:23 PM)bbjimmy Wrote: There is need for only one libyab.so on the system. libyab.so IS backward compatible.
how do want to do that?
i am using yab sience first time. i often have to rebuild many of my programs to get all new features in yab for this in this time because the changes are to deep. so my apps does not run anymore because, for example changes on the window command (position of window be changed). this every month... this was hard and frustrating. if you use all the time the same package name the user can only install this and breaks eventually older programs. if we add at the library a Versionsnumber like all other libraries too we solve this problem. or we need one package, but must be inkluded all Versions. i think this point of libyab is not competly managed and we need to get a solution on this in order to does not break older programs.
what is the problem to compile libyab.so with the version number included?
what kind of problem this have to you?
please do not forget that yab is open source and other ones (jan comes back on r1?) make his own version like you in the Future.
we need version specification
Posts: 245
Threads: 48
Joined: Jun 2015
Reputation:
4
(09-01-2015, 10:30 PM)lelldorin Wrote: how do want to do that?
i am using yab sience first time. i often have to rebuild many of my programs to get all new features in yab for this in this time because the changes are to deep. so my apps does not run anymore because, for example changes on the window command (position of window be changed). this every month... this was hard and frustrating. if you use all the time the same package name the user can only install this and breaks eventually older programs. if we add at the library a Versionsnumber like all other libraries too we solve this problem. or we need one package, but must be inkluded all Versions. i think this point of libyab is not competly managed and we need to get a solution on this in order to does not break older programs.
what is the problem to compile libyab.so with the version number included?
what kind of problem this have to you?
please do not forget that yab is open source and other ones (jan comes back on r1?) make his own version like you in the Future.
we need version specification
This is true, but yab has matured to the point that we are not re-working features and options, but rather adding new options to commands or new commands and not changing / removing old ones.
Even with all the changes made recently to textcontrol, there are no changes that broke older programs. With care, this will continue. If / when there is a break, libyab.so will be re-named to reflect this, and older programs will need to be re-compiled to use the new library. At that point, a libyab.so.hpkg may be required to allow older programs to continue to run.
On the other hand, if we insist on having a libyab package so that our compiled programs can use this as a dependency instead of yab, this triggers the following.
Changing from two .hpkg files for yab to four.
Adding a libyab.hpkg
Adding a Libyab_devel.hpkg
Adding libyab.hpkg as a dependency for the yab .hpkg so that the yab.hpkg no-longer includes this lib.
Adding libyab-devel as a dependency to the yab_ide.hpkg as this will no-longer be included with the yab.hpkg that yab_ide.hpkg depends on.
The /system/lib folder will get a new libyab.so.xx file every time there is a change to yab as libyab is really where the yab code resides even though the library is backward compatible.
Compiled programs will need to refer to libyab.so.xx
Posts: 54
Threads: 7
Joined: Jun 2015
Reputation:
2
(09-02-2015, 09:17 AM)bbjimmy Wrote: This is true, but yab has matured to the point that we are not re-working features and options, but rather adding new options to commands or new commands and not changing / removing old ones.
Who is we? yab is open source. every one can make changes if he like.
(09-02-2015, 09:17 AM)bbjimmy Wrote: Even with all the changes made recently to textcontrol, there are no changes that broke older programs. With care, this will continue. If / when there is a break, libyab.so will be re-named to reflect this, and older programs will need to be re-compiled to use the new library. At that point, a libyab.so.hpkg may be required to allow older programs to continue to run.
Yes you do, but other people?
(09-02-2015, 09:17 AM)bbjimmy Wrote: On the other hand, if we insist on having a libyab package so that our compiled programs can use this as a dependency instead of yab, this triggers the following.
Changing from two .hpkg files for yab to four.
Adding a libyab.hpkg
Adding a Libyab_devel.hpkg
Adding libyab.hpkg as a dependency for the yab .hpkg so that the yab.hpkg no-longer includes this lib.
Adding libyab-devel as a dependency to the yab_ide.hpkg as this will no-longer be included with the yab.hpkg that yab_ide.hpkg depends on.
The /system/lib folder will get a new libyab.so.xx file every time there is a change to yab as libyab is really where the yab code resides even though the library is backward compatible.
Compiled programs will need to refer to libyab.so.xx
I does ot can follow, i does not understand, my english is to bad and my google translation is to confusing
Posts: 163
Threads: 38
Joined: Jun 2015
Reputation:
6
(09-02-2015, 09:17 AM)bbjimmy Wrote: Compiled programs will need to refer to libyab.so.xx
They could. But yab.hpkg will depend on libyab.hpkg so making my app depend on yab will get me access to the libyab file anyway. Same way you could, right now. make your app depend on yab-ide being present. It would not make sense, but it would work.
In fact, if you don't want to maintain so many packages, you might as well fold yab into yab-ide, then you have libyab.hpkg for people who only need to run compiled apps, and yab-ide for everybody else.plus the respective devel packages.
I don't know, it seems like we are creating unnecessary problems for ourselves.
Posts: 26
Threads: 5
Joined: Aug 2015
Reputation:
0
The problem is extract the libyab.so yet to deal with the actual source code depending yab.
Is there a way on the haiku depotserver eg invoke a script?
my thought process is as follows:
The libyab.so appears as a file in haiku depot, but is just a placeholder, because if you would like to install, make a script on the server called and libyab.so is created and afterwards copied to the appropriate place and linked.
Another solution I do not see now. Unless to arrange it back, so that the Yab is linked to the programs.
Posts: 163
Threads: 38
Joined: Jun 2015
Reputation:
6
Sure, you can make a completely empty hpkg called libyab.hpkg that depends on yab.hpkg. You can create libyab.pkg with a post-install-script that compiles libyab.so. for you. But what is the point? Why not just get the user to download yab? They only have to do it once and it's not that big.
Posts: 54
Threads: 7
Joined: Jun 2015
Reputation:
2
(09-03-2015, 05:10 AM)clasqm Wrote: Sure, you can make a completely empty hpkg called libyab.hpkg that depends on yab.hpkg. You can create libyab.pkg with a post-install-script that compiles libyab.so. for you. But what is the point? Why not just get the user to download yab? They only have to do it once and it's not that big.
because if one is only user why he should install a development package to run a program?
i wish that yab programs are get the same feeling like a normal program. if i need to install yab, i ever know this is not a normal program. i hate this talking about yab that it is just a basic dialect, nothing special. yab is so much more and you can do more with it like other basic dialects. so i hope that people who install yab programs does not know that it is a basic program. who should only say, hey great application a good help for me.
if i need to install a lib to run the program is nornaly practice and bound on the binary is great too, but install a complete source and developmrnt inviroment to run a program is not a way if good programming. not user friendly.
Posts: 245
Threads: 48
Joined: Jun 2015
Reputation:
4
For a user there is no difference. He installs a program and one additional .hpkg is installed.
He gets some extra stuff, but nothing is linked into the applications menu from the yab.hpkg. As far as user experiance goes, there is no difference between installing yab or installing libyab.so.
He does get the extra benefit of being able to run a yab script without needing to install another .hpkg.
At this point, re-thinking the issue, I see no reason to have a libyab .hpkg.
If there is a real issue with the current packaging that actually impacts the user or usability, I will change my position, but just to make the user feel that his program is a real program doesn't convince me.
Posts: 54
Threads: 7
Joined: Jun 2015
Reputation:
2
09-03-2015, 11:25 PM
(This post was last modified: 09-04-2015, 01:12 AM by lelldorin.)
(09-03-2015, 10:50 AM)bbjimmy Wrote: For a user there is no difference. He installs a program and one additional .hpkg is installed.
He gets some extra stuff, but nothing is linked into the applications menu from the yab.hpkg. As far as user experiance goes, there is no difference between installing yab or installing libyab.so.
he get a new folder in the home directory called yab. a folder there user add and manage his files.
Quote:He does get the extra benefit of being able to run a yab script without needing to install another .hpkg.
this is true and sounds right but you steel the user his self choosing.
Quote:At this point, re-thinking the issue, I see no reason to have a libyab .hpkg.
the discution does not based to have a libyab.hpkg the discussion based on how to handle yab version problems. if i think i need to release a yablib hpkg package for my apps in order to make them runable and available, i will and need this to do.
Quote:If there is a real issue with the current packaging that actually impacts the user or usability, I will change my position, but just to make the user feel that his program is a real program doesn't convince me.
haiku needs a little bit zeta feeling, because all devs only thinking like devs and not for the users. i see this many times. if you do not think so is it ok, but does not be angry if other people makes his own way to solve this.
and the haiku devs have not many intention to support yab as needed dev language, who prefer c and c++. you know that. things like removing bison and flex out of yab source because this is not needed talks enough to understand my this.
|
