Re: [Gambas-user] About library and component packaging in Gambas 3
On Mon, 2012-05-07 at 01:20 +0200, Benoît Minisini wrote: > The autotools packager should work anyway, even if a component with no > exported class seems to not be really useful. :-) > OK, (but I wouldn't really consider this worth fixing) Source archive for a "no exports" component attached. Here's the output from the ./configure|make|make install for an autotools package made from the project: [bb@bluecow noinfo-0.0.1]$ ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gambas3 binaries... Ok checking for gambas3 components path... Ok configure: creating ./config.status config.status: creating Makefile [bb@bluecow noinfo-0.0.1]$ make Building noinfo component... OK [bb@bluecow noinfo-0.0.1]$ su Password: [root@bluecow noinfo-0.0.1]# make install make[1]: Entering directory `/home/bb/testpkg/noinfo-0.0.1' Installing noinfo.gambas in /usr/local/lib/gambas3 Installing noinfo.component in /usr/local/lib/gambas3 Installing noinfo.info in /usr/local/share/gambas3/info /usr/bin/install: omitting directory `.info' chmod: cannot access `//usr/local/share/gambas3/info/noinfo.info': No such file or directory Installing noinfo.list in /usr/local/share/gambas3/info /usr/bin/install: cannot stat `.list': No such file or directory chmod: cannot access `//usr/local/share/gambas3/info/noinfo.list': No such file or directory make[1]: Nothing to be done for `install-data-am'. make[1]: Leaving directory `/home/bb/testpkg/noinfo-0.0.1' [root@bluecow noinfo-0.0.1]# noinfo-0.0.1.tar.gz Description: application/compressed-tar -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 07/05/2012 01:18, GMail a écrit : >> >> Do you have a ".list" file too ? Can you send me the project ? >> > Sorry Benoît, > > In the clear light of day, I see that this was my error. In a frenzied > fit of code cleaning, I deleted the only class that was exported from > the component :-( > > Bruce > The autotools packager should work anyway, even if a component with no exported class seems to not be really useful. :-) -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Mon, 2012-05-07 at 00:40 +0200, Benoît Minisini wrote: > Le 06/05/2012 04:58, Bruce Bruen a écrit : > > (New sub-thread) ".info" has disappeared > > > > If a project has its type set to "Component" now, when it is compiled > > (or Make Executable) there is no .info file created in the project > > directory any more. > > > > Is this by design? > > > > (Because the autotools install target is still looking for it and > > fails. I can help fix the autotools scripts but I need to know if .info > > has disappeared on purpose.) > > > > Bruce > > > > Do you have a ".list" file too ? Can you send me the project ? > Sorry Benoît, In the clear light of day, I see that this was my error. In a frenzied fit of code cleaning, I deleted the only class that was exported from the component :-( Bruce -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 06/05/2012 04:58, Bruce Bruen a écrit : > (New sub-thread) ".info" has disappeared > > If a project has its type set to "Component" now, when it is compiled > (or Make Executable) there is no .info file created in the project > directory any more. > > Is this by design? > > (Because the autotools install target is still looking for it and > fails. I can help fix the autotools scripts but I need to know if .info > has disappeared on purpose.) > > Bruce > Do you have a ".list" file too ? Can you send me the project ? -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
(New sub-thread) ".info" has disappeared If a project has its type set to "Component" now, when it is compiled (or Make Executable) there is no .info file created in the project directory any more. Is this by design? (Because the autotools install target is still looking for it and fails. I can help fix the autotools scripts but I need to know if .info has disappeared on purpose.) Bruce -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Sat, 05 May 2012, Benoît Minisini wrote: > Le 05/05/2012 15:30, tobi a écrit : > >> > >> OK. > >> But just for interest, what do you mean by "impossible to analyze"? Excuse > >> me, but I haven't read > >> anything from the compiler yet. (When you say "analyze", I think of line > >> numbers and stuff > >> (optimisation can be done later, too, right?), but line numbers would be > >> possible, I'm almost a bit > >> certain, to report to the IDE, if that is what you mean) > >> I just tested it and found that cpp warns at ['] the gambas comment > >> character which, of course, may > >> not ahve any closing ['] one and thus confuses the program but it > >> fearlessly ignores that and > >> continues as expected. > >> > >> ... > > "cpp" means "C PreProcessor". This program was designed (not always > intelligently) for the C-language. > > This is the reason why there is a preprocessor inside the Gambas > compiler dedicated to the Gambas language. > > But this preprocessor is very rudimentary, only the really needed > features being implemented. > > When I say "impossible to analyze", I mean that a preprocessor like > "cpp" is really obfuscating the real code, and so it will prevent the > development from analyzing the code. Then you can say bye-bye to > automatic completion, method arguments popups and so on. > > Regards, > > -- > Benoît Minisini > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Gambas-user mailing list > Gambas-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-user Yes, and even the manpage warns about using cpp with other languages and recommends one that is built especially for the certain language. (Although, I find it rather powerful apart from C) I didn't know the preprocessor was responsible for these nifty things. It seems to already play a great role - I was entirely focused on the directives it provides which permit to think that it wasn't that important and could be easily replaced. Sorry for the noise. Regards, Tobi -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 05/05/2012 15:30, tobi a écrit : >> >> OK. >> But just for interest, what do you mean by "impossible to analyze"? Excuse >> me, but I haven't read >> anything from the compiler yet. (When you say "analyze", I think of line >> numbers and stuff >> (optimisation can be done later, too, right?), but line numbers would be >> possible, I'm almost a bit >> certain, to report to the IDE, if that is what you mean) >> I just tested it and found that cpp warns at ['] the gambas comment >> character which, of course, may >> not ahve any closing ['] one and thus confuses the program but it fearlessly >> ignores that and >> continues as expected. >> >> ... "cpp" means "C PreProcessor". This program was designed (not always intelligently) for the C-language. This is the reason why there is a preprocessor inside the Gambas compiler dedicated to the Gambas language. But this preprocessor is very rudimentary, only the really needed features being implemented. When I say "impossible to analyze", I mean that a preprocessor like "cpp" is really obfuscating the real code, and so it will prevent the development from analyzing the code. Then you can say bye-bye to automatic completion, method arguments popups and so on. Regards, -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Sat, 05 May 2012, tobi wrote: > On Sat, 05 May 2012, Benoît Minisini wrote: > > Le 05/05/2012 08:51, tobi a écrit : > > > > > > Concerning the preprocessor... What about utilising the cpp just as a > > > command that runs over each > > > class and module file before seen by the compiler code? It's already > > > powerful enough or is that > > > too much for gambas? (It would break existing code due to character case > > > in the gambas preprocessor > > > directives...) > > > > > > > Yes, it will slow down the compiler and break everything (because the > > code becomes impossible to analyze) > > > > Regards, > > > > -- > > Benoît Minisini > > > > -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > ___ > > Gambas-user mailing list > > Gambas-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/gambas-user > > OK. > But just for interest, what do you mean by "impossible to analyze"? Excuse > me, but I haven't read > anything from the compiler yet. (When you say "analyze", I think of line > numbers and stuff > (optimisation can be done later, too, right?), but line numbers would be > possible, I'm almost a bit > certain, to report to the IDE, if that is what you mean) > I just tested it and found that cpp warns at ['] the gambas comment character > which, of course, may > not ahve any closing ['] one and thus confuses the program but it fearlessly > ignores that and > continues as expected. > > As an example, consider these actions: > $ ls -AR > .: > .gambas .project .src .startup > > ./.gambas: > > ./.src: > MMain.module myfunc.function > $ cp .src/MMain.module .src/MMain.module.old > $ cat .src/MMain.module > ' Gambas module file > > #ifndef NOPREPROC > #define PREPROC > #endif > > #include "myfunc.function" > > Public Sub Main() > > #ifdef PREPROC > /* >* I can use these comments when c-preprocessed, of course! >*/ > Print "This is cool" > myfunc() > #endif > Print "This is normal" > > End > $ cpp .src/MMain.module.old | sed 's/^#.*$//' > .src/MMain.module > .src/MMain.module:1:1: warning: missing terminating ' character [enabled by > default] > $ gbc3 -ga > OK > $ cp .src/MMain.module.old .src/MMain.module > $ gbx3 > This is cool > preprocessing > This is normal > $ cpp -DNOPREPROC .src/MMain.module.old | sed 's/^#.*$//' > .src/MMain.module > $ gbc3 -ga > OK > $ gbx3 > This is normal > > It works! > Used by people at least a bit familiar with the basics of the cpp won't have > any problems, the only > thing is the translation of the cpp line control which I have discarded > gracefully using sed because > I don't make any mistakes ;) > > It's clear that it would slow down the compiler and that most people won't > need those fancy tricks > as gambas is basic and has advanced enough compiling mechanisms, I'm > convinced, but: a simple line > on the top of a file to enable the cpp for the rest of people that may > utilise it wouldn't hurt?: > ' Gambas class file > ' :use cpp > Please, explain your worries. > > A more intrusive "feature" would be the ability of using that c-/c++-style > comments /**/, // within > gambas when cpp'ed... > > I have no reason to write this post (never needed to used conditional > compilation or something from > within gambas) except to save you work. > > Reagards, > Tobi Oh, you should know: $ cat .src/myfunc.function #ifdef PREPROC Private Sub myfunc() Print "preprocessing" End #endif And forget that $ cp .src/MMain.module.old .src/MMain.module above, it is useless. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Sat, 05 May 2012, Benoît Minisini wrote: > Le 05/05/2012 08:51, tobi a écrit : > > > > Concerning the preprocessor... What about utilising the cpp just as a > > command that runs over each > > class and module file before seen by the compiler code? It's already > > powerful enough or is that > > too much for gambas? (It would break existing code due to character case in > > the gambas preprocessor > > directives...) > > > > Yes, it will slow down the compiler and break everything (because the > code becomes impossible to analyze) > > Regards, > > -- > Benoît Minisini > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Gambas-user mailing list > Gambas-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-user OK. But just for interest, what do you mean by "impossible to analyze"? Excuse me, but I haven't read anything from the compiler yet. (When you say "analyze", I think of line numbers and stuff (optimisation can be done later, too, right?), but line numbers would be possible, I'm almost a bit certain, to report to the IDE, if that is what you mean) I just tested it and found that cpp warns at ['] the gambas comment character which, of course, may not ahve any closing ['] one and thus confuses the program but it fearlessly ignores that and continues as expected. As an example, consider these actions: $ ls -AR .: .gambas .project .src .startup ./.gambas: ./.src: MMain.module myfunc.function $ cp .src/MMain.module .src/MMain.module.old $ cat .src/MMain.module ' Gambas module file #ifndef NOPREPROC #define PREPROC #endif #include "myfunc.function" Public Sub Main() #ifdef PREPROC /* * I can use these comments when c-preprocessed, of course! */ Print "This is cool" myfunc() #endif Print "This is normal" End $ cpp .src/MMain.module.old | sed 's/^#.*$//' > .src/MMain.module .src/MMain.module:1:1: warning: missing terminating ' character [enabled by default] $ gbc3 -ga OK $ cp .src/MMain.module.old .src/MMain.module $ gbx3 This is cool preprocessing This is normal $ cpp -DNOPREPROC .src/MMain.module.old | sed 's/^#.*$//' > .src/MMain.module $ gbc3 -ga OK $ gbx3 This is normal It works! Used by people at least a bit familiar with the basics of the cpp won't have any problems, the only thing is the translation of the cpp line control which I have discarded gracefully using sed because I don't make any mistakes ;) It's clear that it would slow down the compiler and that most people won't need those fancy tricks as gambas is basic and has advanced enough compiling mechanisms, I'm convinced, but: a simple line on the top of a file to enable the cpp for the rest of people that may utilise it wouldn't hurt?: ' Gambas class file ' :use cpp Please, explain your worries. A more intrusive "feature" would be the ability of using that c-/c++-style comments /**/, // within gambas when cpp'ed... I have no reason to write this post (never needed to used conditional compilation or something from within gambas) except to save you work. Reagards, Tobi -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 05/05/2012 08:51, tobi a écrit : > > Concerning the preprocessor... What about utilising the cpp just as a command > that runs over each > class and module file before seen by the compiler code? It's already powerful > enough or is that > too much for gambas? (It would break existing code due to character case in > the gambas preprocessor > directives...) > Yes, it will slow down the compiler and break everything (because the code becomes impossible to analyze) Regards, -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Sat, 05 May 2012, Benoît Minisini wrote: > Le 05/05/2012 03:42, Bruce Bruen a écrit : > > On Sat, 2012-05-05 at 02:45 +0200, Benoît Minisini wrote: > >> Le 04/05/2012 23:34, Benoît Minisini a écrit : > >>> > >>> I don't like any of those solution at the moment. > >>> > >>> And if I define a compilation constant that will tell the compiler if we > >>> are making an executable or not? That way, you will just have to add a > >>> "#If Executable" (or something like that) to compile or not compile the > >>> startup function ? > >>> > >> > >> This is the solution I implemented in revision #4715. Tell me if it fits > >> your needs. > >> > >> Regards, > >> > > Benoît, > > > > I'm trying it but I need a bit of help on usage. (I'm using a library > > that has a startup form not a module. Is this a bad idea?) > > > > Public Sub Form_Open() > > > > #If Executable > >Me.Center > >LoadInfos > > #Else > >Error "This is a library.\nPlease do not run it directly" > >Message.Title = "Don't do that!" > >Message.Error("This is a library.\nPlease do not run it directly", > > "OK") > >Quit > > #Endif > > > > End > > > > If I compile the project and run it via gbx3, I get the expected "Don't > > do that" messages, but if I run it in the IDE I get the same thing. > > > > Bruce > > > > The constant is "Exec". I try to use Gambas keywords, because it is > easier for the preprocessor (that is not entirely finished). > > Regards, > > -- > Benoît Minisini > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Gambas-user mailing list > Gambas-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/gambas-user Concerning the preprocessor... What about utilising the cpp just as a command that runs over each class and module file before seen by the compiler code? It's already powerful enough or is that too much for gambas? (It would break existing code due to character case in the gambas preprocessor directives...) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Sat, 2012-05-05 at 03:59 +0200, Benoît Minisini wrote: > Le 05/05/2012 03:42, Bruce Bruen a écrit : > > On Sat, 2012-05-05 at 02:45 +0200, Benoît Minisini wrote: > >> Le 04/05/2012 23:34, Benoît Minisini a écrit : > >>> > >>> ... > >>> > >>> And if I define a compilation constant that will tell the compiler if we > >>> are making an executable or not? That way, you will just have to add a > >>> "#If Executable" (or something like that) to compile or not compile the > >>> startup function ? > >>> > >> > >> This is the solution I implemented in revision #4715. Tell me if it fits > >> your needs. > >> > The constant is "Exec". I try to use Gambas keywords, because it is > easier for the preprocessor (that is not entirely finished). > > Regards, > OK! I got it now, e.g. Public Sub Main() Debug Application.Startup.Name #If Exec ' This code is executed when running outside the IDE Debug "I am the executable" Error "Please don't run this file!" #Else ' This code is only executed when running inside the IDE Debug "Not an executable" Print "Executing some test code" ' Test1 ' Test2 ' etc #Endif End Yes, it looks as though this will fit our needs. I feel that I need to do some further testing on real example libraries, just to be sure. (But I have some other things to do now, it's Saturday here. So I'll get back to you in a few days.) Bruce -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Thanks, Works fine now. Bruce On Fri, 2012-05-04 at 23:17 +0200, Benoît Minisini wrote: > Le 02/05/2012 06:54, Bruce Bruen a écrit : > > Hi folks! > > > > (I'm getting pretty excited about the packager now.) > > > > > > Benoît, > > > > Please consider this little change for the autotools packager code in > > the IDE. > > > > We use a lot of common images in our projects. Corporate identity etc > > etc blah blah... Rather than have copies of all these in the projects > > we symbolic link them in. (So we only have one set of images to manage > > not lots!) > > > > Unfortunately, the links created in the IDE are relative to the project > > directory, e.g. PHlogo.png would be linked in referencing something > > like "../../common/images/logos/paddys-hill/PHlogo.png" > > > > When the project is copied to the temporary build dir in the packaging > > process, these links are now incorrect. > > > > The following diff (also attached) corrects this by adding the L option > > to the cp command so that symbolic links are snapped. > > > > Index: Package.module > > === > > --- Package.module(revision 4702) > > +++ Package.module(working copy) > > @@ -1383,7 +1383,7 @@ > > Try sCmd = Scan(Project.GetCompileCommand(True, Not > > Project.KeepDebugInfo, False), "*/bin/gbc"& System.Version& " *")[1] > > > > 'Mkdir sBuildDir&/ Project.Name > > - Shell "cp -r "& Shell$(Project.Dir)& " "& Shell$(sBuildDir&/ > > Project.Name) Wait > > + Shell "cp -rL "& Shell$(Project.Dir)& " "& Shell$(sBuildDir&/ > > Project.Name) Wait > > sFile = Replace(File.Load("install/acinclude.m4"), "$(VERSION)", > > CStr(System.Version)) > > sFile = Replace(sFile, "$(PACKAGE_VERSION)", $sVersion) > > sFile = Replace(sFile, "$(EXTRA_TEST)", Project.ExtraAutoconfTest) > > > > > > regards > > Bruce > > > > OK, done. > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Fri, 2012-05-04 at 23:19 +0200, Benoît Minisini wrote: > Le 04/05/2012 15:25, Bruce Bruen a écrit : > > Subtopic autotools > > > > autotools now works like a dream. We have been distributing stuff via > > autotools for several days now and have only come across the following > > problem. > > > > "make uninstall" (as root) appears to work but in fact doesn't. Given > > that we have installed "sysinfos-0.0.2.tar.gz" via the usual > >unpack/cd src dir/ config/make/(root)make install > > then we can see it quite well via: > > > > [root@bluecow ~]# which sysinfos.gambas > > /usr/local/bin/sysinfos.gambas > > > > However, when I try to use the "uninstall" target, I get: > > > > [root@bluecow sysinfos-0.0.2]# make uninstall > > Removing sysinfos.gambas file... rm /usr/local/bin/sysinfos.gambas > > [root@bluecow sysinfos-0.0.2]# > > > > I think a "-f" option is missing to the 'rm' command thre. I will add it > in the next revision, and you will tell me if it works. > > Regards, > Benoît, Also missing a ";" on the previous line! Diff attached Bruce Index: Makefile.am === --- Makefile.am(revision 4715) +++ Makefile.am(working copy) @@ -48,7 +48,7 @@ rm -f $(DESTDIR)/$(GBINFO_path)/$(PACKAGE).list; \ rm -rf $(DESTDIR)/$(GBCONTROL_path)/$(PACKAGE); \ else \ - echo "Removing $(PACKAGE).gambas file..." \ + echo "Removing $(PACKAGE).gambas file..."; \ rm -f $(DESTDIR)$(bindir)/$(PACKAGE).gambas; \ fi) -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 05/05/2012 03:42, Bruce Bruen a écrit : > On Sat, 2012-05-05 at 02:45 +0200, Benoît Minisini wrote: >> Le 04/05/2012 23:34, Benoît Minisini a écrit : >>> >>> I don't like any of those solution at the moment. >>> >>> And if I define a compilation constant that will tell the compiler if we >>> are making an executable or not? That way, you will just have to add a >>> "#If Executable" (or something like that) to compile or not compile the >>> startup function ? >>> >> >> This is the solution I implemented in revision #4715. Tell me if it fits >> your needs. >> >> Regards, >> > Benoît, > > I'm trying it but I need a bit of help on usage. (I'm using a library > that has a startup form not a module. Is this a bad idea?) > > Public Sub Form_Open() > > #If Executable >Me.Center >LoadInfos > #Else >Error "This is a library.\nPlease do not run it directly" >Message.Title = "Don't do that!" >Message.Error("This is a library.\nPlease do not run it directly", > "OK") >Quit > #Endif > > End > > If I compile the project and run it via gbx3, I get the expected "Don't > do that" messages, but if I run it in the IDE I get the same thing. > > Bruce > The constant is "Exec". I try to use Gambas keywords, because it is easier for the preprocessor (that is not entirely finished). Regards, -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Sat, 2012-05-05 at 02:45 +0200, Benoît Minisini wrote: > Le 04/05/2012 23:34, Benoît Minisini a écrit : > > > > I don't like any of those solution at the moment. > > > > And if I define a compilation constant that will tell the compiler if we > > are making an executable or not? That way, you will just have to add a > > "#If Executable" (or something like that) to compile or not compile the > > startup function ? > > > > This is the solution I implemented in revision #4715. Tell me if it fits > your needs. > > Regards, > Benoît, I'm trying it but I need a bit of help on usage. (I'm using a library that has a startup form not a module. Is this a bad idea?) Public Sub Form_Open() #If Executable Me.Center LoadInfos #Else Error "This is a library.\nPlease do not run it directly" Message.Title = "Don't do that!" Message.Error("This is a library.\nPlease do not run it directly", "OK") Quit #Endif End If I compile the project and run it via gbx3, I get the expected "Don't do that" messages, but if I run it in the IDE I get the same thing. Bruce -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 04/05/2012 23:34, Benoît Minisini a écrit : > > I don't like any of those solution at the moment. > > And if I define a compilation constant that will tell the compiler if we > are making an executable or not? That way, you will just have to add a > "#If Executable" (or something like that) to compile or not compile the > startup function ? > This is the solution I implemented in revision #4715. Tell me if it fits your needs. Regards, -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 01/05/2012 13:27, Bruce Bruen a écrit : > On Tue, 2012-05-01 at 12:22 +0200, Benoît Minisini wrote: >> A lot of answers to a lot of stuff, so I'm going to break it up into >> several posts. > >> Le 29/04/2012 06:45, Bruce Bruen a écrit : >>> >>> SUGGESTION: Libraries should not need to have a startup class. At >>> the moment I "must" include a dummy module to prevent any >>> test-harness code leaking into the user environment (which could >>> cause damage if the library were to be run as a normal gambas >>> executable.) At the moment the IDE will not let a library be made >>> into an executable or packaged unless it has a startup class. It >>> would be preferable that projects defined as libraries would not >>> execute via the runtime, that way test harness code could be left in >>> place. Currently I have to check that the coders have left the >>> startup class pointing to the following:- >>> >>> ' Gambas module file >>> >>> ' Null module to provide a fake startup point >>> >>> Public Sub Main() >>> >>> Error "Please do not run this as a program. It is a gambas library." >>> >>> End >>> >> >> Mmm. You are right, for libraries the IDE should let you not defined a >> startup class. I will see what I can do. >> > I think that ("the IDE should let you not defined a startup class") is > an overkill. What I need is a way to use a startup class in a library > when I'm developing it but when it is packaged the startup class should > be "removeable". > > To explain, during development/debug/support for a library, we need to > be able to run it as a normal project through the IDE. This is what I > meant about "test harnesses". In general, we have a MMain module in the > library that may, or in fact usually, contains code that lets us enter > method parameter values manually. This type of code if used by an > ill-advised user could cause great havoc on an underlying database or > the like. > > What I would like is a way to manually disable or "turn off" the startup > class when the library project is made as an executable or is packaged. > > I suppose that the alternative is to not allow startup classes in > libraries or components and keep changing the project type to "Normal" > when we are debugging/supporting but I can foresee a lot of mistakes if > that route is chosen. > > The way I see it is this. (Hypothetically) I've just spent some time on > the phone to Mr Jones and it appears that there is, amazingly, a problem > in the xyzzzy library. I open the xyzzy project and using the test > harness code therein I find that we did in fact code a logic error when > some date parameter to a dual timezone function is exactly the date and > time that daylight savings changed in one of the timezones. ( I kid you > not, this happened recently!) So I give the problem to the wizkids, er > sorry, my brilliant development team, and they come up with a nicely > tested solution. > > So now all I want to do is turn off the startup class, compile and make > the distributable version and send it out. > > With a bit of thought... maybe what libraries/components need is a > startup class that only works within the IDE... > > hmm! > > Bruce > I don't like any of those solution at the moment. And if I define a compilation constant that will tell the compiler if we are making an executable or not? That way, you will just have to add a "#If Executable" (or something like that) to compile or not compile the startup function ? -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 01/05/2012 14:15, Bruce Bruen a écrit : > Oh I forgot! > > A new problem. Spaces in the vendor name cause fails in the rpm > builder. > > This is not a high priority issue, but it would be nice if spaces in the > "Vendor name" field in the wizard were converted to underscores before > it was used in the rpm build. > > But then again, it's probably only an issue to imbeciles like me that > register their company name as something like "Paddys-Hill dot Net". > > > best regards > (I'm going to bed now) > > Bruce > OK, I have converted spaces to underscore in vendor name for the next revision. Regards, -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 04/05/2012 15:25, Bruce Bruen a écrit : > Subtopic autotools > > autotools now works like a dream. We have been distributing stuff via > autotools for several days now and have only come across the following > problem. > > "make uninstall" (as root) appears to work but in fact doesn't. Given > that we have installed "sysinfos-0.0.2.tar.gz" via the usual >unpack/cd src dir/ config/make/(root)make install > then we can see it quite well via: > > [root@bluecow ~]# which sysinfos.gambas > /usr/local/bin/sysinfos.gambas > > However, when I try to use the "uninstall" target, I get: > > [root@bluecow sysinfos-0.0.2]# make uninstall > Removing sysinfos.gambas file... rm /usr/local/bin/sysinfos.gambas > [root@bluecow sysinfos-0.0.2]# > I think a "-f" option is missing to the 'rm' command thre. I will add it in the next revision, and you will tell me if it works. Regards, -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 02/05/2012 06:54, Bruce Bruen a écrit : > Hi folks! > > (I'm getting pretty excited about the packager now.) > > > Benoît, > > Please consider this little change for the autotools packager code in > the IDE. > > We use a lot of common images in our projects. Corporate identity etc > etc blah blah... Rather than have copies of all these in the projects > we symbolic link them in. (So we only have one set of images to manage > not lots!) > > Unfortunately, the links created in the IDE are relative to the project > directory, e.g. PHlogo.png would be linked in referencing something > like "../../common/images/logos/paddys-hill/PHlogo.png" > > When the project is copied to the temporary build dir in the packaging > process, these links are now incorrect. > > The following diff (also attached) corrects this by adding the L option > to the cp command so that symbolic links are snapped. > > Index: Package.module > === > --- Package.module(revision 4702) > +++ Package.module(working copy) > @@ -1383,7 +1383,7 @@ > Try sCmd = Scan(Project.GetCompileCommand(True, Not > Project.KeepDebugInfo, False), "*/bin/gbc"& System.Version& " *")[1] > > 'Mkdir sBuildDir&/ Project.Name > - Shell "cp -r "& Shell$(Project.Dir)& " "& Shell$(sBuildDir&/ > Project.Name) Wait > + Shell "cp -rL "& Shell$(Project.Dir)& " "& Shell$(sBuildDir&/ > Project.Name) Wait > sFile = Replace(File.Load("install/acinclude.m4"), "$(VERSION)", > CStr(System.Version)) > sFile = Replace(sFile, "$(PACKAGE_VERSION)", $sVersion) > sFile = Replace(sFile, "$(EXTRA_TEST)", Project.ExtraAutoconfTest) > > > regards > Bruce > OK, done. -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Subtopic autotools autotools now works like a dream. We have been distributing stuff via autotools for several days now and have only come across the following problem. "make uninstall" (as root) appears to work but in fact doesn't. Given that we have installed "sysinfos-0.0.2.tar.gz" via the usual unpack/cd src dir/ config/make/(root)make install then we can see it quite well via: [root@bluecow ~]# which sysinfos.gambas /usr/local/bin/sysinfos.gambas However, when I try to use the "uninstall" target, I get: [root@bluecow sysinfos-0.0.2]# make uninstall Removing sysinfos.gambas file... rm /usr/local/bin/sysinfos.gambas [root@bluecow sysinfos-0.0.2]# which appears to have worked at face value, but in actual fact /usr/local/bin/sysinfos.gambas still exists!! [root@bluecow sysinfos-0.0.2]# ll /usr/local/bin/sys* -rwxr-xr-x 1 root root 6820 May 4 22:08 /usr/local/bin/sysinfos.gambas* (I have also tried the "make uninstall-am" and "make unistall-locall" with no better result, but I don't think that is an issue.) Observations: 1) There doesn't seem to be an "uninstall" target in the makefiles that I can see so I can't add any value here. 2) Although, obviously root could simply "rm /usr/local/bin/sysinfos.gambas", there really should be a working target. regards Bruce p.s. The source (and autotools) packages for "sysinfos" is in the related post "Distributing Libraries etc". -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Hi folks! (I'm getting pretty excited about the packager now.) Benoît, Please consider this little change for the autotools packager code in the IDE. We use a lot of common images in our projects. Corporate identity etc etc blah blah... Rather than have copies of all these in the projects we symbolic link them in. (So we only have one set of images to manage not lots!) Unfortunately, the links created in the IDE are relative to the project directory, e.g. PHlogo.png would be linked in referencing something like "../../common/images/logos/paddys-hill/PHlogo.png" When the project is copied to the temporary build dir in the packaging process, these links are now incorrect. The following diff (also attached) corrects this by adding the L option to the cp command so that symbolic links are snapped. Index: Package.module === --- Package.module(revision 4702) +++ Package.module(working copy) @@ -1383,7 +1383,7 @@ Try sCmd = Scan(Project.GetCompileCommand(True, Not Project.KeepDebugInfo, False), "*/bin/gbc" & System.Version & " *")[1] 'Mkdir sBuildDir &/ Project.Name - Shell "cp -r " & Shell$(Project.Dir) & " " & Shell$(sBuildDir &/ Project.Name) Wait + Shell "cp -rL " & Shell$(Project.Dir) & " " & Shell$(sBuildDir &/ Project.Name) Wait sFile = Replace(File.Load("install/acinclude.m4"), "$(VERSION)", CStr(System.Version)) sFile = Replace(sFile, "$(PACKAGE_VERSION)", $sVersion) sFile = Replace(sFile, "$(EXTRA_TEST)", Project.ExtraAutoconfTest) regards Bruce Index: Package.module === --- Package.module(revision 4702) +++ Package.module(working copy) @@ -1383,7 +1383,7 @@ Try sCmd = Scan(Project.GetCompileCommand(True, Not Project.KeepDebugInfo, False), "*/bin/gbc" & System.Version & " *")[1] 'Mkdir sBuildDir &/ Project.Name - Shell "cp -r " & Shell$(Project.Dir) & " " & Shell$(sBuildDir &/ Project.Name) Wait + Shell "cp -rL " & Shell$(Project.Dir) & " " & Shell$(sBuildDir &/ Project.Name) Wait sFile = Replace(File.Load("install/acinclude.m4"), "$(VERSION)", CStr(System.Version)) sFile = Replace(sFile, "$(PACKAGE_VERSION)", $sVersion) sFile = Replace(sFile, "$(EXTRA_TEST)", Project.ExtraAutoconfTest)-- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Oh I forgot! A new problem. Spaces in the vendor name cause fails in the rpm builder. This is not a high priority issue, but it would be nice if spaces in the "Vendor name" field in the wizard were converted to underscores before it was used in the rpm build. But then again, it's probably only an issue to imbeciles like me that register their company name as something like "Paddys-Hill dot Net". best regards (I'm going to bed now) Bruce -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Tue, 2012-05-01 at 12:22 +0200, Benoît Minisini wrote: in reply to my > > I tried using the Mandriva and Fedora RPM based packaging, which > > allowed me to create proper looking distribution packages, but ... > > > > When I tested the installation locally I run into the following > > problem. There is a dependency requirement on "gambas-runtime" > > version 3.blahblah ... This makes sense except that there is no > > "gambas-runtime" for my home made system, I build and install from > > the source archive. Also, this is how we have set it (gambas) up on > > all the client's machines. Is there a way to remove this dependency > > from being included in the RPM package build? > > A binary package system relies of being used totally. You cannot have > some of the dependencies outside of it (i.e. installed from sources), it > breaks the system. > > This is the reason why Gambas should be packaged eveywhere. :-/ > This, of course, makes perfect sense in a binary distro world. All I can say is "Such is life!". ("Cest la vie?" ??? I dunno, my high school French memories seem to have faded.) Sigh! I suppose that I, or one of the code-pixies, are going to learn how to package Gambas itself. :-) rgrds Bruce -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Tue, 2012-05-01 at 12:22 +0200, Benoît Minisini wrote: > In reply to my: > > Not sure about this as far as the autotools packager is concerned. > > The icon.png is certainly in the gzip file (but is this because > > autotools is a "source" level package?) > > autotools is not reliable at the moment as it didn't get the same recent > modifications as the other package types. Lately the autotools package has been very stable! In fact that is how we are currently distributing the apps to 28 customers (yes, I lost a couple to a very feature poor windows web based app... but they'll be back!) I wrote a gambas app that runs the autotools "extract / reconf / configure / make" series and that gets them updated with very few problems. If I could just find a way of running the "su/sudo/whatever make install" bit across 28 different "distros" I'd be ecstatic! My comment was only an observation regarding the inclusion of project icons in packages. rgrds Bruce -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On Tue, 2012-05-01 at 12:22 +0200, Benoît Minisini wrote: > A lot of answers to a lot of stuff, so I'm going to break it up into several > posts. > Le 29/04/2012 06:45, Bruce Bruen a écrit : > > > > SUGGESTION: Libraries should not need to have a startup class. At > > the moment I "must" include a dummy module to prevent any > > test-harness code leaking into the user environment (which could > > cause damage if the library were to be run as a normal gambas > > executable.) At the moment the IDE will not let a library be made > > into an executable or packaged unless it has a startup class. It > > would be preferable that projects defined as libraries would not > > execute via the runtime, that way test harness code could be left in > > place. Currently I have to check that the coders have left the > > startup class pointing to the following:- > > > > ' Gambas module file > > > > ' Null module to provide a fake startup point > > > > Public Sub Main() > > > > Error "Please do not run this as a program. It is a gambas library." > > > > End > > > > Mmm. You are right, for libraries the IDE should let you not defined a > startup class. I will see what I can do. > I think that ("the IDE should let you not defined a startup class") is an overkill. What I need is a way to use a startup class in a library when I'm developing it but when it is packaged the startup class should be "removeable". To explain, during development/debug/support for a library, we need to be able to run it as a normal project through the IDE. This is what I meant about "test harnesses". In general, we have a MMain module in the library that may, or in fact usually, contains code that lets us enter method parameter values manually. This type of code if used by an ill-advised user could cause great havoc on an underlying database or the like. What I would like is a way to manually disable or "turn off" the startup class when the library project is made as an executable or is packaged. I suppose that the alternative is to not allow startup classes in libraries or components and keep changing the project type to "Normal" when we are debugging/supporting but I can foresee a lot of mistakes if that route is chosen. The way I see it is this. (Hypothetically) I've just spent some time on the phone to Mr Jones and it appears that there is, amazingly, a problem in the xyzzzy library. I open the xyzzy project and using the test harness code therein I find that we did in fact code a logic error when some date parameter to a dual timezone function is exactly the date and time that daylight savings changed in one of the timezones. ( I kid you not, this happened recently!) So I give the problem to the wizkids, er sorry, my brilliant development team, and they come up with a nicely tested solution. So now all I want to do is turn off the startup class, compile and make the distributable version and send it out. With a bit of thought... maybe what libraries/components need is a startup class that only works within the IDE... hmm! Bruce -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Am Dienstag, den 01.05.2012, 12:22 +0200 schrieb Benoît Minisini: > Le 29/04/2012 06:45, Bruce Bruen a écrit : > > > > SUGGESTION: Libraries should not need to have a startup class. At > > the moment I "must" include a dummy module to prevent any > > test-harness code leaking into the user environment (which could > > cause damage if the library were to be run as a normal gambas > > executable.) At the moment the IDE will not let a library be made > > into an executable or packaged unless it has a startup class. It > > would be preferable that projects defined as libraries would not > > execute via the runtime, that way test harness code could be left in > > place. Currently I have to check that the coders have left the > > startup class pointing to the following:- > > > > ' Gambas module file > > > > ' Null module to provide a fake startup point > > > > Public Sub Main() > > > > Error "Please do not run this as a program. It is a gambas library." > > > > End > > > > Mmm. You are right, for libraries the IDE should let you not defined a > startup class. I will see what I can do. Salut, I didn't follow your discussion, but I use since years exactly that . My programs are both libraries and standalone executables. So I can chain them ! 1.) My 'crm', calls a 'switch', which calls the 'report tool', which is calling the 'report viewer' 2.) My 'crm', calls a 'switch', which is calling the 'report viewer' 3.) My 'switch', calls the 'report tool', which is calling the 'report viewer' 4.) My 'switch', calls the 'report viewer' 5.) My 'report tool', calls the 'report viewer' 6.) Start just the 'report viewer' Please don't break that! -- Amicalement Charlie -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 29/04/2012 06:45, Bruce Bruen a écrit : > > SUGGESTION: Libraries should not need to have a startup class. At > the moment I "must" include a dummy module to prevent any > test-harness code leaking into the user environment (which could > cause damage if the library were to be run as a normal gambas > executable.) At the moment the IDE will not let a library be made > into an executable or packaged unless it has a startup class. It > would be preferable that projects defined as libraries would not > execute via the runtime, that way test harness code could be left in > place. Currently I have to check that the coders have left the > startup class pointing to the following:- > > ' Gambas module file > > ' Null module to provide a fake startup point > > Public Sub Main() > > Error "Please do not run this as a program. It is a gambas library." > > End > Mmm. You are right, for libraries the IDE should let you not defined a startup class. I will see what I can do. > Not sure about this as far as the autotools packager is concerned. > The icon.png is certainly in the gzip file (but is this because > autotools is a "source" level package?) autotools is not reliable at the moment as it didn't get the same recent modifications as the other package types. >> - The package has dependencies on other components and libraries >> checked in the project properties dialog. > This is unclear. I was under the assumption that the Project > Properties dialog Components and Libraries tabs indicated the items > that are needed when running the library within the IDE (i.e. in test > mode) and the Component Properties dialog defined the dependencies > for the library when it runs as a library i.e. in another application > (whether that application is running in the IDE or via gbx3). > > We use a few "private" libraries to develop and test the libraries > we distribute to users and the approach I have been using is to > include them in the "Project Properties" dialog but not the > "Component Properties" dialog. (Again, this relates back to > including test harness code in the library and perhaps Issue 123.) > Could you clarify please. > Sorry, this is unclear indeed. You are right, it works like components: dependencies are managed by the IDE from the *component/library* property dialog. What is checked in the project property dialog is taken into account only when running the library as a normal project. Usually, dependencies defined in the project property dialog (used when compiling the project) are the same as those defined in the component property dialog (the true runtime dependencies). But this is not mandatory. > Further, it is unclear what the "Extra Dependencies" step in the RPM > based packagers is for? Perhaps a little note in the header, similar > to the "Extra files" step. They are dependencies added to the package dependency list verbatim. These should be name of packages of the target distribution. For example, if your project uses a system library through extern calls, you should add it to the extra dependencies. Because Gambas cannot do that automatically, as the name of the library binary package depends on the target distribution. > >> >> 2) COMPONENT >> >> - There is a library/component properties dialog. - No icon is >> packaged. - No menu entry is defined in the package. - If the >> project has control icons, they are packaged. - The package name is >> "gambas-vendor-projectname-X.Y.Z" where "X.Y.Z" is the version. - >> The vendor prefix is mandatory, it is "gb" by default. - The >> package has no dependencies on other components and libraries. This >> is supposed to be managed directly by the IDE. Components are a >> special beast that should be included directly in Gambas sources. > Again,this last bit is unclear. We use some custom control > components in our product. Some of which have dependencies on native > gb components, e.g. gb.db and at least one of which is dependent on > another home grown component (i.e. our "phDataControls" component is > dependent on both gb.db and our "phBaseControls" component. This has > worked fine until now. I haven't checked this yet but does it mean > that from 4687 on, that this will no longer work? See the explanation above. Components and libraries dependencies work the same way now. > >> >> 3) NORMAL PROJECT >> >> - There is no library/component properties dialog. - The "make >> executable" dialog can create a desktop shortcut automatically. - >> The packager has an icon and a menu entry. - The package name is >> "ProjectName-X.Y.Z" where "X.Y.Z" is the version. - The vendor can >> be added as a prefix optionally. - The package has dependencies on >> other components and libraries checked in the project properties >> dialog. >> >> Please try it and give your remarks! >> >> Regards, >> > > I have checked the autotools packaging (which is how we have > hitherto been distributing our product to end users) and it works > fine. > > I tried
Re: [Gambas-user] About library and component packaging in Gambas 3
Hi Benoit, A few comments inline... regards Bruce On Sat, 2012-04-28 at 15:26 +0200, Benoît Minisini wrote: > Hi, > > I'm continue in fixing problems in library and component packaging. Here > are the last news... > > Since revision #4687, there is now a project type option in the project > properties dialog, which allows to make the difference between a normal > project, a library and a component. > > What are the differences between the three types? > > 1) LIBRARY SUGGESTION: Libraries should not need to have a startup class. At the moment I "must" include a dummy module to prevent any test-harness code leaking into the user environment (which could cause damage if the library were to be run as a normal gambas executable.) At the moment the IDE will not let a library be made into an executable or packaged unless it has a startup class. It would be preferable that projects defined as libraries would not execute via the runtime, that way test harness code could be left in place. Currently I have to check that the coders have left the startup class pointing to the following:- ' Gambas module file ' Null module to provide a fake startup point Public Sub Main() Error "Please do not run this as a program. It is a gambas library." End > > - There is a library/component properties dialog. > - No icon is packaged. Not sure about this as far as the autotools packager is concerned. The icon.png is certainly in the gzip file (but is this because autotools is a "source" level package?) > - No menu entry is defined in the package. > - The package name is "projectname-X.Y.Z" where "X.Y.Z" is the version. > - The vendor can be added as a prefix optionally. Are there any pros and cons here? > - The package has dependencies on other components and libraries checked > in the project properties dialog. This is unclear. I was under the assumption that the Project Properties dialog Components and Libraries tabs indicated the items that are needed when running the library within the IDE (i.e. in test mode) and the Component Properties dialog defined the dependencies for the library when it runs as a library i.e. in another application (whether that application is running in the IDE or via gbx3). We use a few "private" libraries to develop and test the libraries we distribute to users and the approach I have been using is to include them in the "Project Properties" dialog but not the "Component Properties" dialog. (Again, this relates back to including test harness code in the library and perhaps Issue 123.) Could you clarify please. Further, it is unclear what the "Extra Dependencies" step in the RPM based packagers is for? Perhaps a little note in the header, similar to the "Extra files" step. > > 2) COMPONENT > > - There is a library/component properties dialog. > - No icon is packaged. > - No menu entry is defined in the package. > - If the project has control icons, they are packaged. > - The package name is "gambas-vendor-projectname-X.Y.Z" where "X.Y.Z" is > the version. > - The vendor prefix is mandatory, it is "gb" by default. > - The package has no dependencies on other components and libraries. > This is supposed to be managed directly by the IDE. Components are a > special beast that should be included directly in Gambas sources. Again,this last bit is unclear. We use some custom control components in our product. Some of which have dependencies on native gb components, e.g. gb.db and at least one of which is dependent on another home grown component (i.e. our "phDataControls" component is dependent on both gb.db and our "phBaseControls" component. This has worked fine until now. I haven't checked this yet but does it mean that from 4687 on, that this will no longer work? > > 3) NORMAL PROJECT > > - There is no library/component properties dialog. > - The "make executable" dialog can create a desktop shortcut automatically. > - The packager has an icon and a menu entry. > - The package name is "ProjectName-X.Y.Z" where "X.Y.Z" is the version. > - The vendor can be added as a prefix optionally. > - The package has dependencies on other components and libraries checked > in the project properties dialog. > > Please try it and give your remarks! > > Regards, > I have checked the autotools packaging (which is how we have hitherto been distributing our product to end users) and it works fine. I tried using the Mandriva and Fedora RPM based packaging, which allowed me to create proper looking distribution packages, but ... When I tested the installation locally I run into the following problem. There is a dependency requirement on "gambas-runtime" version 3.blahblah ... This makes sense except that there is no "gambas-runtime" for my home made system, I build and install from the source archive. Also, this is how we have set it (gambas) up on all the client's machines. Is there a way to remove this dependency from being included in the RPM package build? reg
Re: [Gambas-user] About library and component packaging in Gambas 3
Le 29/04/2012 00:14, Willy Raets a écrit : > On za, 2012-04-28 at 15:26 +0200, Benoît Minisini wrote: >> Please try it and give your remarks! >> > Tested with revision 4688 > > Quite an improvement. > Library packages just fine. > Upon installation Ubuntu recognizes it as a library (see screenshot > library). > > Application depending on library gives a strange message in Ubuntu > Software Center, but does install (see screenshot before and after) > Some small bug in packaging? > > Great work...thanks, > > Willy > Can you give me the messages you get when installing your packages with "apt-get install" and not with the Ubuntu Software Center (which often crashes on my machine)? -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] About library and component packaging in Gambas 3
On za, 2012-04-28 at 15:26 +0200, Benoît Minisini wrote: > Hi, > > I'm continue in fixing problems in library and component packaging. Here > are the last news... > > Since revision #4687, there is now a project type option in the project > properties dialog, which allows to make the difference between a normal > project, a library and a component. > Great going, I'm looking forward to a test run this evening. > What are the differences between the three types? > > 1) LIBRARY > > - There is a library/component properties dialog. > - No icon is packaged. > - No menu entry is defined in the package. > - The package name is "projectname-X.Y.Z" where "X.Y.Z" is the version. > - The vendor can be added as a prefix optionally. > - The package has dependencies on other components and libraries checked > in the project properties dialog. > > 2) COMPONENT > > - There is a library/component properties dialog. > - No icon is packaged. > - No menu entry is defined in the package. > - If the project has control icons, they are packaged. > - The package name is "gambas-vendor-projectname-X.Y.Z" where "X.Y.Z" is > the version. > - The vendor prefix is mandatory, it is "gb" by default. > - The package has no dependencies on other components and libraries. > This is supposed to be managed directly by the IDE. Components are a > special beast that should be included directly in Gambas sources. > > 3) NORMAL PROJECT > > - There is no library/component properties dialog. > - The "make executable" dialog can create a desktop shortcut automatically. > - The packager has an icon and a menu entry. > - The package name is "ProjectName-X.Y.Z" where "X.Y.Z" is the version. > - The vendor can be added as a prefix optionally. > - The package has dependencies on other components and libraries checked > in the project properties dialog. > > Please try it and give your remarks! > Clearly explained and I'll get back to you later. Many thanks as I can use this very well. This really boosts up possibilities being able to decently distribute libraries. Willy -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
[Gambas-user] About library and component packaging in Gambas 3
Hi, I'm continue in fixing problems in library and component packaging. Here are the last news... Since revision #4687, there is now a project type option in the project properties dialog, which allows to make the difference between a normal project, a library and a component. What are the differences between the three types? 1) LIBRARY - There is a library/component properties dialog. - No icon is packaged. - No menu entry is defined in the package. - The package name is "projectname-X.Y.Z" where "X.Y.Z" is the version. - The vendor can be added as a prefix optionally. - The package has dependencies on other components and libraries checked in the project properties dialog. 2) COMPONENT - There is a library/component properties dialog. - No icon is packaged. - No menu entry is defined in the package. - If the project has control icons, they are packaged. - The package name is "gambas-vendor-projectname-X.Y.Z" where "X.Y.Z" is the version. - The vendor prefix is mandatory, it is "gb" by default. - The package has no dependencies on other components and libraries. This is supposed to be managed directly by the IDE. Components are a special beast that should be included directly in Gambas sources. 3) NORMAL PROJECT - There is no library/component properties dialog. - The "make executable" dialog can create a desktop shortcut automatically. - The packager has an icon and a menu entry. - The package name is "ProjectName-X.Y.Z" where "X.Y.Z" is the version. - The vendor can be added as a prefix optionally. - The package has dependencies on other components and libraries checked in the project properties dialog. Please try it and give your remarks! Regards, -- Benoît Minisini -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user