Main place for discussions about U++ cross platform development framework.
Hello All, I didn't find if exist a method for set include option for specific package. I thing that it is a possibility to add "compiler option" in package organizer, but if exists more explicit method which i do not know, please tell me. I want continue to develop wrapper xlslib package started by Koldo. This will be great because in include option will be not need to add the full path of include directory, but on compiling process, IDE will add full path. Another opportunity is increasing compilation process: specific include folders by package will set in case the developer will use this packages with specific include option. In base of xlslib package we will add in package organizer for link option only: /lib/common /lib/xlslib /lib/oledoc /lib/data This realization can be uses in sdl package too, or in other external plugins. I hope I was clear Thank you in advance.
Hello all Yes I agree. It would be interesting to have in, for example, "Package Organizer", a way to include something like "New Include" in here Best regards Koldo
It's possible to put new include paths at "New compiler option", so I don't see why have another "Include" option when you can control the compiler so easy.
andrei_natanael wrote on Wed, 10 June 2009 17:28 It's possible to put new include paths at "New compiler option", so I don't see why have another "Include" option when you can control the compiler so easy. In "New compiler option" is possibility to add not full path directory?
AFAIK, yes: -I/usr/include These options are transparently used on the compile command line. Matthias
masu wrote on Wed, 10 June 2009 18:15 AFAIK, yes: -I/usr/include These options are transparently used on the compile command line. Matthias I tried, it didn't compiled, because the default directory is not package directory. I can try this to add and propose to Mirek. this is a minor change!
It works for me, I just moved a header file in one of my projects to "C:\temp" and added Compiler option -Ic:/temp to the main package. Then I changed references to the moved header to <xxx.h> (I used "xxx.h" before) and it is found and the project compiles. You may also have to change your references to header file then. Matthias
masu wrote on Wed, 10 June 2009 18:42 It works for me, I just moved a header file in one of my projects to "C:\temp" and added Compiler option -Ic:/temp to the main package. Then I changed references to the moved header to <xxx.h> (I used "xxx.h" before) and it is found and the project compiles. You may also have to change your references to header file then. Matthias Ok, I thing that I will be understanding in real example: I have a package located in: D:\ILupascu\sourcecode\cpp\upp\MyApps\xlslib\ I need add include libs for directories: D:\ILupascu\sourcecode\cpp\upp\MyApps\xlslib\lib\src\oledoc\ D:\ILupascu\sourcecode\cpp\upp\MyApps\xlslib\lib\src\xlslib\ D:\ILupascu\sourcecode\cpp\upp\MyApps\xlslib\lib\src\common\ D:\ILupascu\sourcecode\cpp\upp\MyApps\xlslib\lib\src\data\ As you see this is located in sub folder of package. this package I can relocated and include libraries will located too. I propose to add in Package organizer an option "Include option" that in option will be only: /lib/src/oledoc /lib/src/xlslib /lib/src/common /lib/src/data In compiling the package which have this include options or use an package which have this compiling option, U++ will set to compiler include option the full path of this 4 directories. If I do not use this option U++ will not set this include options. Like this situation I can add as example SDL packages.
Why don't you do it like this? You only need to specify a long path once for each include dir in your xls package. Matthias
Why? Because the package I can relocated and include libraries will automatic located too (I mean the full path) masu wrote on Wed, 10 June 2009 19:16 Why don't you do it like this? You only need to specify a long path once for each include dir in your xls package. Matthias
Why do you need the full path? The paths you want to include are all relative to xls (or whatever your package name is), right? You should be able to move the xls package into another assembly and add this package to your project, the include paths are automatically included within xls.h. Matthias
I'm thinking, for instance, MySQL or PostgreSQL. They do not contain the PostgreSQL includes nor libs. When I compiled it the first time, I had to go to Setup>Build methods and add PostgreSQL to my include path, the full path. I didn't know about the specific compiler options that I learned here. However, I think a nice Include/Lib path setup like found in Setup>Build per package would be a nice addition. It's something many people have to do.
Hello all I have included the directories in the Package Organizer using the -I option. It works for GCC/MinGW and MSC. So for both compilers the program works well. For now perhaps it is enough but I think it is nicer to include the include directories as an explicit Package option... ... But I have a problem with MSC: Both XlsLibs and \Microsoft SDKs\Windows\v6.1\Include have a file named rectypes.h To avoid errors, XlsLib directories have to be before SDK directories. Unfortunately it seems Upp - First reads Build Methods - Second reads Package Organizer So in this case: - Or I have to do dirty things: renaming rectypes.h in SDKs - Or I have to put XlsLib include directories in Build Methods, and before \Microsoft SDKs\Windows\v6.1\Include Best regards Koldo
koldo wrote on Thu, 11 June 2009 00:58 Hello all I have included the directories in the Package Organizer using the -I option. It works for GCC/MinGW and MSC. So for both compilers the program works well. For now perhaps it is enough but I think it is nicer to include the include directories as an explicit Package option... ... But I have a problem with MSC: Both XlsLibs and \Microsoft SDKs\Windows\v6.1\Include have a file named rectypes.h To avoid errors, XlsLib directories have to be before SDK directories. Unfortunately it seems Upp - First reads Build Methods - Second reads Package Organizer So in this case: - Or I have to do dirty things: renaming rectypes.h in SDKs - Or I have to put XlsLib include directories in Build Methods, and before \Microsoft SDKs\Windows\v6.1\Include Best regards Koldo Very interesting detail. To avoid this situation should be add first package include and after then standard builds. This situation is another motivation to add this include option. Ion Lupascu (tojocky)
jeremy_c wrote on Wed, 10 June 2009 20:35 I'm thinking, for instance, MySQL or PostgreSQL. They do not contain the PostgreSQL includes nor libs. When I compiled it the first time, I had to go to Setup>Build methods and add PostgreSQL to my include path, the full path. I didn't know about the specific compiler options that I learned here. However, I think a nice Include/Lib path setup like found in Setup>Build per package would be a nice addition. It's something many people have to do. For MySQL and PostgreSQL you cannot include these definitions within the wrapper package, because they are installed Upp-external, i.e. they could be located elsewhere on different machines. That is why you must set the paths manually. Matthias
Yes, I understand, but I could configure the include path on my local box for the PostgreSQL package, if the package based include dialog existed, is what I was thinking? Jeremy
jeremy_c wrote on Thu, 11 June 2009 06:18 Yes, I understand, but I could configure the include path on my local box for the PostgreSQL package, if the package based include dialog existed, is what I was thinking? Jeremy Packages are designed to be uncoupled from actual host (either platform or even development computer), that is why adding any paths to package definition is definitely not a good idea. Mirek
luzr wrote on Thu, 11 June 2009 20:13 Packages are designed to be uncoupled from actual host (either platform or even development computer), that is why adding any paths to package definition is definitely not a good idea. Mirek Hello Mirek! But if is a wrapper package for a speciffic lib (example xlslib) and this speciffic lib is ported in wrapper package (sub directory) I thing that it is sense. This lib can be cross-os too and can be uncoupled from actual host. It Is sense because it is not need to modify include prepocesors (correct from #include <header.h> to #include "header.h"). Another method is to add an wizard to import package (files in project) with option correct include tags. Best idea I thing that need add both methods!
Right, but I should add the include directory to postgresql in my global setup, so that it affects all projects? I figured that per install, per package I could set where my package of postgresql should be able to find it's libs/includes. Jeremy
jeremy_c wrote on Thu, 11 June 2009 15:02 Right, but I should add the include directory to postgresql in my global setup, so that it affects all projects? Yes. It is least troublesome. Mirek
Hello Mirek, I added the minimal changes for future: include options for specific package, I hope it is correct. Can you check my changes? Dirrectory path is same as files <directory>{\<directory>} Ex: lib\common If is accepted I can add more wizard things(select directory path dialog, set full path or short path). Include order, I should add first UPP directory (GetVar("UPP"), after then include directories by package uses and after then add global include path. The source code is written very clear and professional. Thank you to U++ authors and contribuitors! Of course, exist things that can be optimized (in my point of view)! I was attached only changed files. Any suggestions is welcome!
I have not possibility to add in a message to files for show an screenshot example: Here I tested xlslib example added by Koldo in U++.
Well, to make things sure... Is all this about #include <header.h> in existing code? (instead of #include "header.h" or something like that). I am not quite sure about it either. In ANY CASE, it should NOT accept absolute paths, or at least, warn about them. Mirek
luzr wrote on Mon, 15 June 2009 10:15 Well, to make things sure... Is all this about #include <header.h> in existing code? (instead of #include "header.h" or something like that). I am not quite sure about it either. In ANY CASE, it should NOT accept absolute paths, or at least, warn about them. Mirek I agree with you about warn when set full path in include option by package. Another question is where need to add include option by package by order? After GetVar("UPP")? can I add it in svn with all changes requested?
I have added "Add to include path" file option that hopefully solves this problem. IMO, it is less faulty than adding include paths for package and, in the end, maybe even slightly easier to use. Mirek
luzr wrote on Sun, 21 June 2009 20:22 I have added "Add to include path" file option that hopefully solves this problem. IMO, it is less faulty than adding include paths for package and, in the end, maybe even slightly easier to use. Mirek For me, I spent minim 1hour to understand how it works. It is not so simple to understand, I thing that you have little complicated realization. I do not know how the new u++ developers will acomodate with this. May be I'm single so slowly. I would like to know other opinions!
Ehm, the only thing to understand is that if you active "Add to include path" for file, then the file can be found using include path. Is that so hard?
Hello luzr Sorry, I do not understand For example in case xlslib: - We have these files to compile lib\src\xlslib\blank.cpp, lib\src\xlslib\cbridge.cpp, lib\src\xlslib\cell.cpp, ... total 30 files ... - These files have includes located in here: lib/src/common, lib/src/data, lib/src/oledoc, lib/src/xlslib; (you can see that all the paths are under package directory) - And the compiler has to use these directories before the included in Setup/Build Methods How would it have to be done with the new "Add to include path" option ? Best regards Koldo
Add any include file you want to include, or take .cpp file in the same dir (in many cases, you will want to have it in package anyway), use "Add to include path" for this include.
luzr wrote on Tue, 23 June 2009 13:30 Add any include file you want to include, or take .cpp file in the same dir (in many cases, you will want to have it in package anyway), use "Add to include path" for this include. I thing that this realization is not transparent, especially for new u++ developers. Is more simple to add maximum 4 directories of include path that find in tens or hundreds source (*.cpp, *h) files if exist "include path by package". Maybe we need to vote what is good and what is bad between our realizations. If is any new proposes, it is very good.
tojocky wrote on Wed, 10 June 2009 10:39 Hello All, I didn't find if exist a method for set include option for specific package. I thing that it is a possibility to add "compiler option" in package organizer, but if exists more explicit method which i do not know, please tell me. Hello, Ion. I think, you can achieve this by using new Assembly. Just add necessary include directories to Package nest. For example, we have MyApps assembly: Package nest: C:\MyApps;C:\upp\uppsrc Output directory: C:\upp\out Assembly name: MyApps In building process TheIDE will add directories from Package nest to include search path ("-I") before directories configured in Build methods for specific compiler. Example for MSC9: "C:\Program Files\Microsoft Visual Studio 9.0\Vc\Bin\cl.exe" -nologo -W3 -GR -c \ -I"C:\MyApps" -I"C:\upp\uppsrc" \ -I"C:\Program Files\Microsoft Visual Studio 9.0\Vc\Include" \ -I"C:\Program Files\Microsoft SDKs\Windows\v6.1\Include"
Sender Ghost wrote on Tue, 23 June 2009 15:36 Hello, Ion. I think, you can achieve this by using new Assembly. Just add necessary include directories to Package nest. For example, we have MyApps assembly: Package nest: C:\MyApps;C:\upp\uppsrc Output directory: C:\upp\out Assembly name: MyApps In building process TheIDE will add directories from Package nest to include search path ("-I") before directories configured in Build methods for specific compiler. Example for MSC9: "C:\Program Files\Microsoft Visual Studio 9.0\Vc\Bin\cl.exe" -nologo -W3 -GR -c \ -I"C:\MyApps" -I"C:\upp\uppsrc" \ -I"C:\Program Files\Microsoft Visual Studio 9.0\Vc\Include" \ -I"C:\Program Files\Microsoft SDKs\Windows\v6.1\Include" The goal is to optimize include option! I have MyApp directory, that contains more packages. Only few packages use specific include (actual is only xlslib).
Hello Mirek I have tried to compile xlslib with the available options but I do not know how. This library has a tree of 42 include files called between them and from 32 .cpp files, that I am not able to compile in a simple portable way. I think that the Ion proposal included below is the simpler from an user point of view using, as Ion does, relative paths like "lib/src/common". However I have total confidence in your final decision that I will accept without further discussion. Best regards Koldo tojocky wrote on Sun, 14 June 2009 09:08 I have not possibility to add in a message to files for show an screenshot example: Here I tested xlslib example added by Koldo in U++.
Well, I am sorry to be stubborn, I am just STRONGLY opposed to the idea that package should have any explicit include paths. Mirek
tojocky wrote on Tue, 23 June 2009 07:18 luzr wrote on Tue, 23 June 2009 13:30 Add any include file you want to include, or take .cpp file in the same dir (in many cases, you will want to have it in package anyway), use "Add to include path" for this include. I thing that this realization is not transparent, especially for new u++ developers. Is more simple to add maximum 4 directories of include path that find in tens or hundreds source (*.cpp, *h) files if exist "include path by package". That one is simple. It is reflected in file's icon... Mirek
In my current opinion, you just want to use unsuitable tool. Packages are independent from absolute paths, therefore they are portable. If you saw U++ code organization you can understand how your code must be organized to accomplish U++ modules approach. Assembly "knows" about absolute paths and where to find Packages (which is disguised form of include search path directories for compiler). So, changes for paths should be on Assembly level. I suggest you to use new Assembly, e.g. XlsLibApps with following options: Package nest: C:\XlsLibApps;C:\XlsLibApps\lib\src\oledoc; \ C:\XlsLibApps\lib\src\xlslib;C:\XlsLibApps\lib\src\common; \ C:\XlsLibApps\lib\src\data;C:\MyApps;C:\upp\uppsrc Output directory: C:\upp\out Assembly name: XlsLibApps to Mirek: You can improve selection of Package nest directories or just add new option (e.g. ArrayCtrl) for include search paths. Edit: Anyway, we all have suitable solutions for this problem. I just want to show another point of view.
Sender Ghost wrote on Tue, 23 June 2009 11:25 In my current opinion, you just want to use unsuitable tool. Packages are independent from absolute paths, therefore they are portable. If you saw U++ code organization you can understand how your code must be organized to accomplish U++ modules approach. Assembly "knows" about absolute paths and where to find Packages (which is disguised form of include search path directories for compiler). So, changes for paths should be on Assembly level. I suggest you to use new Assembly, e.g. XlsLibApps with following options: Package nest: C:\XlsLibApps;C:\XlsLibApps\lib\src\oledoc; \ C:\XlsLibApps\lib\src\xlslib;C:\XlsLibApps\lib\src\common; \ C:\XlsLibApps\lib\src\data;C:\MyApps;C:\upp\uppsrc Output directory: C:\upp\out Assembly name: XlsLibApps to Mirek: You can improve selection of Package nest directories or just add new option (e.g. ArrayCtrl) for include search paths. Actually, the intended place for include path is build method... Anyway, the problem we are trying to solve here is that when adapting existing code as U++ package (in this case, existing library capable of parsing XLS files), you have to solve the issue that sources can have its own directory structure, including special folders for .h. Up to now, we usually fixed the issue by editing sources (#include <foo/bar.h> -> #include "bar.h"). Anyway, I have to agree that it can get long in teeth over time. That is why I agree there is some problem to solve. But based on experience with "Add any file" to package, I would like to stay clean of any form hinting to the idea that the package is the place to define include path... Mirek
luzr wrote on Tue, 23 June 2009 18:09 Well, I am sorry to be stubborn, I am just STRONGLY opposed to the idea that package should have any explicit include paths. Mirek By "explicit include paths" you mean full path? If Yes, I can add possibility to restrict to set full path for the include package include option.
tojocky wrote on Tue, 23 June 2009 15:15 luzr wrote on Tue, 23 June 2009 18:09 Well, I am sorry to be stubborn, I am just STRONGLY opposed to the idea that package should have any explicit include paths. Mirek By "explicit include paths" you mean full path? Any path But package based path is more tolerable... Mirek
I think there have been misunderstandings luzr wrote on Tue, 23 June 2009 23:26 tojocky wrote on Tue, 23 June 2009 15:15 luzr wrote on Tue, 23 June 2009 18:09 Well, I am sorry to be stubborn, I am just STRONGLY opposed to the idea that package should have any explicit include paths. Mirek By "explicit include paths" you mean full path? Any path But package based path is more tolerable... Mirek Have I heard that before ? Quote: I think that the Ion proposal included below is the simpler from an user point of view using, as Ion does, relative paths like "lib/src/common". ... relative paths under package directory. The thing I did not want to do was precisely this: Quote: Up to now, we usually fixed the issue by editing sources (#include <foo/bar.h> -> #include "bar.h"). ... as I prefer not to modify library sources, but for "force majeure". I think Ion and me agree from the beginning that for a wrapper, the library sources tree begins from package folder. We only want to say the compiler how to look for #includes there. Best regards Koldo
luzr wrote on Tue, 23 June 2009 17:09 Well, I am sorry to be stubborn, I am just STRONGLY opposed to the idea that package should have any explicit include paths. Mirek +1 That would make packages hard to relocate easily, like now.
Hello mr_ped Nobody in this thread wants absolute paths mr_ped wrote on Wed, 24 June 2009 10:09 luzr wrote on Tue, 23 June 2009 17:09 Well, I am sorry to be stubborn, I am just STRONGLY opposed to the idea that package should have any explicit include paths. Mirek +1 That would make packages hard to relocate easily, like now. We only want paths relative to package folder and under it. For example, this diagram: Why this. For making wrappers to other libraries. Situations: 1. Library directory structure is very simple: Nothing to do 2. Library directory structure is not very simple. Solutions: 2.1 Change library source code. In my opinion this is ugly 2.2 Put the library tree under Upp package and compile it seting include path structure under Upp package. This is something we like. Best regards Koldo
I agree with Koldo! Maybe I proposed not finished variant. but we can restrict for do not permit to set absolute paths koldo wrote on Wed, 24 June 2009 11:59 Hello mr_ped Nobody in this thread wants absolute paths mr_ped wrote on Wed, 24 June 2009 10:09 luzr wrote on Tue, 23 June 2009 17:09 Well, I am sorry to be stubborn, I am just STRONGLY opposed to the idea that package should have any explicit include paths. Mirek +1 That would make packages hard to relocate easily, like now. We only want paths relative to package folder and under it. For example, this diagram: Why this. For making wrappers to other libraries. Situations: 1. Library directory structure is very simple: Nothing to do 2. Library directory structure is not very simple. Solutions: 2.1 Change library source code. In my opinion this is ugly 2.2 Put the library tree under Upp package and compile it seting include path structure under Upp package. This is something we like. Best regards Koldo
Well, OK, sorry for the resistance. I have tried, my proposal, although solving the problem, is rejected. I will add tojocky's method ASAP. The only thing to consider is some better name that would indicate that the whole issue is really only useful for incorporating 3rd party libraries.... Mirek
Thank you Mirek, Sorry us for the resistance too! If you have not time for this, I can propose the final variant to restrict access for any path, and integrate FileSel to select folder. With respect, Ion Lupascu (tojocky) luzr wrote on Wed, 24 June 2009 20:38 Well, OK, sorry for the resistance. I have tried, my proposal, although solving the problem, is rejected. I will add tojocky's method ASAP. The only thing to consider is some better name that would indicate that the whole issue is really only useful for incorporating 3rd party libraries.... Mirek
luzr wrote on Sun, 28 June 2009 22:53 Done. Hello Mirek, Nice realization, but..... my realization it adds internal include package for current build package and for uses packages. In your realization add internal include package only fro current build package. I want to discuss about this, how is correct. Your realization is good when I do a package which wrap a library. In my case (XLSLIB) it is not work because I use direct link to library from other package! OK, Question: Is correct to add include package for uses packages too? My opinion: it is necessary to add (by priority) inlcude internal package for uses packages.
Changed: All packages now using internal include paths. Mirek
luzr wrote on Mon, 29 June 2009 20:56 Changed: All packages now using internal include paths. Mirek Hello Mirek! It is better, but analyzing package structure, for example: If only XLS Lib package have internal include then on building need add only for: XLS_LIB and Current_Package. For other packages as CtrlLib, CtrlCore, and other is not need to add!
tojocky wrote on Tue, 30 June 2009 10:42 luzr wrote on Mon, 29 June 2009 20:56 Changed: All packages now using internal include paths. Mirek Hello Mirek! It is better, but analyzing package structure, for example: If only XLS Lib package have internal include then on building need add only for: XLS_LIB and Current_Package. For other packages as CtrlLib, CtrlCore, and other is not need to add! Can it do any real harm? The only thing comes to mind is the same name of header. Mirek
luzr wrote on Tue, 30 June 2009 18:17 Can it do any real harm? The only thing comes to mind is the same name of header. Mirek Yes, I thing too! May have situation when is same name of header!