Patches item #3581737, was opened at 2012-10-29 16:36 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3581737...
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Federico Schwindt (fgsch) Assigned to: Nobody/Anonymous (nobody) Summary: OpenBSD support
Initial Comment: FIrst round of patches to add support for OpenBSD.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody) Date: 2012-11-06 04:45
Message: I might be missing something but unless you add it manually I don't see where configures adds the HAVE_XXX to CFLAGS unless you do it manually.
And src/makefile.in is processed by src/configure(.in) so only ../configure.ac and ../src/configure.in need to be modified.
<rant> You have a pretty messed up build system. </rant>
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 03:57
Message: if the patch comes from git, then please create a branch, commit to that and then create a patch-set using "git format-patch master".
as for the HAVE_ALLOCA_H: if you don't instruct configure to write defines into config.h, it will add them to the CFLAGS, so that the compilation will still work. thus, no need to change the build-system. bear in mind though, that currently Pd uses to separate build-systems: .../configure.ac and .../src/configure.in (and .../src/makefile.nt); you might need to modify all 3 in order to get accepted (yes, it's a PITA)
----------------------------------------------------------------------
Comment By: Federico Schwindt (fgsch) Date: 2012-11-06 02:48
Message: @zmoelnig:
The patch comes from git. My main concern is how to proceed with the other changes that require more changes than just extending an existing ifdef. For example the exclusion of alloca.h, etc. In my git clone I've modified configure to use config headers and so I can do ifdef HAVE_ALLOCA_H, etc. but I'm not sure if such patches will be accepted. The reason I've break them down is so they can be committed while I understand what your preference is.
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-11-06 02:39
Message: this patch is simple enough (almost trivial) as it only adds "#ifdef __OpenBSD__" to the clauses that are already handled by "__FreeBSD__". i don't see a reason to not include it (but of course this all depends on miller).
small note on patches: - the patch doesn't apply here (`patch` thinks the diff is garbage) - Pd is developped in git; it would be great if you could generate your patches using git as well; see [1] - as for atomicity of patches: personally i think creating a (few) smaller patches is not a real problem; make sure that those patches are logical units rather than reflecting your iterative trial-and-error history to fix a problem. then attach all patch files to this ticket (rather than creating a new patchtracker-ticket for each file)
[1] http://puredata.info/docs/developer/GitWorkflows/
----------------------------------------------------------------------
Comment By: Federico Schwindt (fgsch) Date: 2012-11-06 02:03
Message: Comments please? I'd really to move forward with this. Thanks.
----------------------------------------------------------------------
Comment By: Federico Schwindt (fgsch) Date: 2012-10-29 19:01
Message: That'd be ideal but since I'm not sure about the other changes (using config headers, etc.) I'm submitting what I know for certain that won't change depending on the approach.
For example what should I do if alloca.h doesn't exist? In my git repo I have #ifdef HAVE_ALLOCA_H where the define is driven from autotools header check but I'm still unclear whether you want to use the headers or not (and the reason you might not want to do it since you're already using autotools).
Happy to submit everything in one go if you can suggest what the best course of action is.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-10-29 18:57
Message: The best thing to do would be to make a single patch that includes everything needed for OpenBSD support.
----------------------------------------------------------------------
You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3581737...