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.
H
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 :-(
>
> Br
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
>
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 autotool
(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 c
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 an
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?),
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? I
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
>
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
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 comp
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
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
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.
> >
>
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
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 wi
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 c
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
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 us
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
>
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 bl
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 u
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
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
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. T
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 th
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" includ
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 environ
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 g
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
>
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
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
32 matches
Mail list logo