nanogui: Thread: #if FOO vs. #ifdef BAR

Hi,

e.g. in engine/devfont.c you can find the following code:

#ifdef HAVE_PCF_SUPPORT
	if (fontclass == MWLF_CLASS_ANY || fontclass == MWLF_CLASS_PCF) {
...
#endif

#if HAVE_FREETYPE_SUPPORT
 	if (fontclass == MWLF_CLASS_ANY || fontclass == MWLF_CLASS_FREETYPE) {
...


which is slightly confusing.
Which of both is the preferred style ?
If somebody will commit, I'll send a patch :-)

What is actually the current state of cvs access ?

Bye
Alex
--
Work: ####@####.#### - http://www.jenoptik-los.de
Home: ####@####.####                - http://www.kde.org
      ####@####.####               - http://www.neundorf.net

Hi

* Alexander Neundorf [Tue, 31 May 2005 at 22:43 +0200]
<quote>
> Hi,
> 
> e.g. in engine/devfont.c you can find the following code:
> 
> #ifdef HAVE_PCF_SUPPORT
> 	if (fontclass == MWLF_CLASS_ANY || fontclass == MWLF_CLASS_PCF) {
> ...
> #endif
> 
> #if HAVE_FREETYPE_SUPPORT
>  	if (fontclass == MWLF_CLASS_ANY || fontclass == MWLF_CLASS_FREETYPE) {
> ...
> 
> 
> which is slightly confusing.
> Which of both is the preferred style ?

I personally prefer #ifdef rather than #if. However what is the opinion of
the maintainer ?

> If somebody will commit, I'll send a patch :-)

Actually there are lots of such case in Nanox source code so if a patch
is written I don't think it should only limitate to the devfont.c file.
But on the other side, patching all similar case of the source code would
make a rather large patch which would become harder to commit. ....
 
> What is actually the current state of cvs access ?

The IP address problem ? It seems to have been fixed. I tried several time
tonight and get everytime directed to the correct IP address.
However no patch can be commited into the CVS until the version 0.91 get
released.

Alain
> 
> Bye
> Alex
> --
> Work: ####@####.#### - http://www.jenoptik-los.de
> Home: ####@####.####                - http://www.kde.org
>       ####@####.####               - http://www.neundorf.net
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
</quote>

	

	
		
_____________________________________________________________________________ 
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com

On Wednesday 01 June 2005 16:13, Alain Volmat wrote:
> Hi
...
> > What is actually the current state of cvs access ?
>
> The IP address problem ? It seems to have been fixed. I tried several time
> tonight and get everytime directed to the correct IP address.
> However no patch can be commited into the CVS until the version 0.91 get
> released.

Yes, this second part.
What's the plan for 0.91 ?
Merging all existing patches done by Greg ?
Merging patches is a lot of work, so I'm afraid this will still take some 
time.

How about giving more people commit access but only allowing commits after an 
ok the mailing list ? (and reverting every unreviewed patch)

This would be a chance to get microwindows development up on speed :-)

Bye
Alex
-- 
Work: ####@####.#### - http://www.jenoptik-los.de
Home: ####@####.####                - http://www.kde.org
      ####@####.####               - http://www.neundorf.net

Hi,

* Alexander Neundorf [Thu,  2 Jun 2005 at 01:26 +0200]
<quote>
> On Wednesday 01 June 2005 16:13, Alain Volmat wrote:
> > Hi
> ...
> > > What is actually the current state of cvs access ?
> >
> > The IP address problem ? It seems to have been fixed. I tried several time
> > tonight and get everytime directed to the correct IP address.
> > However no patch can be commited into the CVS until the version 0.91 get
> > released.
> 
> Yes, this second part.
> What's the plan for 0.91 ?
> Merging all existing patches done by Greg ?
> Merging patches is a lot of work, so I'm afraid this will still take some 
> time.

No, 0.91 will be exactly (or with very minor change .. like changelog etc)
same as the current CVS (or microwindows-src-snapshot.tar.gz). I guess it
should be out within few days.

All pending patches will go under a reviewing process and when accepted 
should find their way in 0.92
The 0.92 work will I think start AFTER the 0.91 release since for now
no CVS commit is possible (because the CVS of 0.91 hasn't yet been fixed).

There were a discussion about that on the mailing list recently, maybe you
might want to check the archive to see that.

Regards,

Alain

> How about giving more people commit access but only allowing commits after an 
> ok the mailing list ? (and reverting every unreviewed patch)
> 
> This would be a chance to get microwindows development up on speed :-)
> 
> Bye
> Alex
> -- 
> Work: ####@####.#### - http://www.jenoptik-los.de
> Home: ####@####.####                - http://www.kde.org
>       ####@####.####               - http://www.neundorf.net
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
</quote>

	

	
		
_____________________________________________________________________________ 
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com

On 2 Jun 2005, at 01:08, Alain Volmat wrote:
> The 0.92 work will I think start AFTER the 0.91 release since for now
> no CVS commit is possible (because the CVS of 0.91 hasn't yet been  
> fixed).

You could create a branch for the 0.91 release and start working on  
what will become 0.92 in the head.

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer

The thing is that I'm not the guy who has permission of the CVS :D

One solution (some guys already mentioned that recently on the ML) 
would be have a development tree. In a sense, this would be useful
since it is better to properly test modifications BEFORE commiting
them into the CVS (Greg insists on testing modifications with all
configurations of screen type for example ... well it makes sences).

The thing is that nanoX isn't a that big project and I'm not sure
that such tree (like the mm tree of the linux kernel) is really necessary.
Moreover it might even make maintenance work harder.

What's other guys opinion ?

Alain

* Alex Holden [Thu,  2 Jun 2005 at 09:30 +0100]
<quote>
> On 2 Jun 2005, at 01:08, Alain Volmat wrote:
> >The 0.92 work will I think start AFTER the 0.91 release since for now
> >no CVS commit is possible (because the CVS of 0.91 hasn't yet been  
> >fixed).
> 
> You could create a branch for the 0.91 release and start working on  
> what will become 0.92 in the head.
> 
> -- 
> ------------ Alex Holden - http://www.alexholden.net/ ------------
> If it doesn't work, you're not hitting it with a big enough hammer
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
</quote>

	

	
		
_____________________________________________________________________________ 
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com

Hi,

On Thursday 02 June 2005 15:33, Alain Volmat wrote:
> The thing is that I'm not the guy who has permission of the CVS :D
>
> One solution (some guys already mentioned that recently on the ML)
> would be have a development tree. In a sense, this would be useful
> since it is better to properly test modifications BEFORE commiting
> them into the CVS (Greg insists on testing modifications with all
> configurations of screen type for example ... well it makes sences).
>
> The thing is that nanoX isn't a that big project and I'm not sure
> that such tree (like the mm tree of the linux kernel) is really necessary.
> Moreover it might even make maintenance work harder.
>
> What's other guys opinion ?

IMO an experimental branch/tree would be a good idea. There stuff can be added 
more easily and can be tested by more developers/users.

Bye
Alex
-- 
Work: ####@####.#### - http://www.jenoptik-los.de
Home: ####@####.####                - http://www.kde.org
      ####@####.####               - http://www.neundorf.net

: #ifdef HAVE_PCF_SUPPORT

: #if HAVE_FREETYPE_SUPPORT

: Which of both is the preferred style ?

The preferred style at this time is the "#if" option, since
in some cases we use the preprocessor OR "|" capability,
and we don't have to wrap everything with ...defined(xxx)...

The downside is that "#if" technically should fail if the value isn't
defined, although most compilers let this through.

This is another area that should probably be cleaned up after
we run the 0.92 patches through...

Regards,

Greg